Jesse I Pollard, II writes:
> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
>> Jesse I Pollard, II writes:
>>> [Albert Cahalan]
>>>> Jesse I Pollard, II writes:
>>>>> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
>>>>>> Jesse I Pollard, II writes:
>>>>>>> Pavel Machek <pavel@suse.cz>:
>>> The "proper" search tool requires me to read the header of
>>> each file in the system to determine if it carries any embedded
>>> capabilities. This takes too long on large file systems.
>>
>> No, you have no reason to care about that. Do you also scan
>> to code itself to see if it might try to delete your files?
>> An elfcap executable is inert without the setuid marking.
>>
>> Why is it that you worry your security admins might put the
>> setuid bit on random files? This is insanity. Such admins are just
>> as likely to set capability bits on random files -- then what?
>> Each case is as auditable as the other.
>
> Not done deliberately. Done because it was hidden.
> For practical systems, no one has the time needed to
> audit every file or executable.
Mount filesystems "noexec" to stop such trojans cold.
Why make work for yourself? (now I know where the military
budget is going)
>> By your criteria, any file at all is a trojan. One of your crazy
>> admins might look at /bin/rm and think, "hey, that needs to be
>> able to delete any file, so I'll just grant it DAC override".
>
> Any file COULD be a trojan. Those files with capabilities set via elfcap
> capabilities are MORE LIKELY to be a trojan. This is an increase in risk.
>
> Obviously you've never had to audit a system in detail.
> It takes a LONG time to do.
My main system is audited to New OT IV. I find that, early on, a few
rockslams help to reduce the size of a cluster. Case Cracker Rundown
was really good. Right now my new PC is getting Power Processing.
Don't make work for yourself.
>>>>>>> they may have passed the initial testing and appear as quite normal
>>>>>>> applications UNTIL they are run as root. Even on a system with root
>>>>>>> having no privileges, suddenly this program becomes privileged.
>>>>>>
>>>>>> See, there is your mistake. It is foolish to think that it is
>>>>>> practical to have root without privileges. Just disable the account.
>>>>>> (set the password entry to '*' or adjust the kernel as desired)
>>>>>
>>>>> Works fine on many systems.
>>>>
>>>> I'm sure it works "fine" until an app screws up. The world is
>>>> filled with code that assumes UID 0 is special. You aren't serious
>>>> about security until you stop allowing UID 0 processes.
>>>
>>> app screws up..??.. I have yet to see an app that depends on uid 0 for
>>> proper operation. I have seen some that use it to determine whether to
>>> do additional things (sendmail is one).
>>
>> Yes, that is exactly the problem. Apps often allow special access
>> for UID 0, but you wanted to make UID 0 be a normal user.
>> Remember that client apps may pass credentails over a socket,
>> so you may end up with fully privileged code granting unintended
>> access to the user with UID 0.
>
> 1. UID 0 should have no special privileges.
Well, it does, and it is not safe to assume you can change this.
Stay away from UID values above 0xfff0 too.
> 2. client apps may NOT pass credentials over a socket.
> No security whatsoever there.
Linux already allows this. With a more extreme system, NT 4.0
recently passed a security qualification WITH A NETWORK running.
FreeBSD has the feature, and I'm fairly sure OpenBSD does too.
>>> No. Initial installation is done during single user mode (all
>>> capabilities set). After multiuser mode is started, that is cleared
>>> (and at the beginning of the multi-user startup too). To install
>>> privileged programs first requires the process (shell) to be
>>> authorized by the system/security administrator. The user so
>>> authorized must log in, using the proper procedures. To activate
>>> the privilege it must be added to the active set. Then the
>>> capabilities can be added to an executable file.
>>>
>>> At each step (login/activate privilege capability/adding capabilities
>>> to the file) is a security event, that can be logged and audited.
>>
>> You can get the same damn thing with elfcap.
>>
>> 1. Require a capability bit to make setuid-root files
>> 2. Only let that bit be active when running a special tool
>> 3. Have the tool enforce whatever policy you like
>
> You weren't paying attention - there are no privileges as root.
> setuid is only a capability. It allows switching uid's, nothing else.
You weren't paying attention - root is NOT to be used as a
normal user. There was an early Trusted IRIX that passed
evaluation with a superuser root.
You might wish UNIX were designed differently, but wishing
doesn't make it so. UID 0 is special, like it or not.
If you really can find all the UID 0 assumptions, then we'd
all like you to apply your super-hacker abilities to something
more important. We have a perfectly serviceable workaround
for the all-powerful root: don't have the account.
> you have to scan EVERY file and look for capabilities.
> The "setuid" file is just the one that is active.
This is utter nonsense.
>>>> Security is reduced because existing admin scripts will not find
>>>> the XFS or ext2 extensions. Capability bits have enough trouble
>>>> with compatibility just by design; filesystem hacks make them worse.
>>>
>>> They arn't extensions. The bits have been there from the
>>> first time I looked at the internals of the file system.
>>
>> I don't see them in "struct stat" and I can't find a way to
>> make the find command list anything odd. Anyway, neither would
>> even help with all the old admin scripts.
>
> Not the in memory struct, look at the disk resident bits. There are a
> LOT of definitions there, including an auxilary inode number, ACL inode
> entry,.
Oh, sure, the unimplemented stuff. Looking at the inode struct,
you'd think we had support for fragments (sub-block allocation) too.
Reserved struct members are nothing without real code.
>>> The adavantage of the inode method is in the association of
>>> the capabilities with the inode that uses them. If the file is
>>> deleted, the capabilities are too. The in-memory implementation
>>> allows for the possiblitiy of the file being replaced without
>>> the list being updated. This possiblity is one that cannot be
>>> worked around.
>>
>> What do you mean by this? The in-memory list would block any
>> attempt to replace the files. The files are immutable. If you
>> refer to the initial list, as loaded by LILO or init scripts,
>> then there are ways to deal with that too. Missing files could
>> halt the boot. Cryptographically strong checksums could be
>> verified during boot.
>
> No it doesn't - if the user has write access to the file then
> the contents can be replaced. This is only prevented by the
> immutable attribute, which is an inode "capability".
The kernel can consider any file to be immutable, even without an
immutable bit on disk. Everything can be done as in-memory data.
Apparent "write access" means nothing to the kernel.
It is no problem to lock down parent directories too.
>>> Look at the RSBAC project for an active implementation of all of this
>>> http://www.rsbac.de/
>>
>> That isn't exactly inode-based.
>
> I know that - it is an in-memory implementation using a file.
> It IS the most complete implementation of a secure Linux system
> that I know of.
Most likely so, though there are now at least two other MAC projects.
SGI is hacking and porting, while somebody else started a project to
get a solid Mandatory Integrity feature for stopping system crackers.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:37 EST