Joseph Gooch writes:
> [Albert D. Cahalan]
>> Jesse I Pollard, II writes:
>>> "Albert D. Cahalan" <acahalan@cs.uml.edu>:
>>>> Jesse I Pollard, II writes:
>>>>> Pavel Machek <pavel@suse.cz>:
>>>>>> Fine. You have no problems with elfcap, then. Noone has
>> setuid 0 bit,
Woah! Watch that word wrap. I'll try to fix the latter wraps.
>>> [snip -- about using UID 0 as a normal user]
>>
>> 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.
>
> No argument here. Only problem being last I knew, elfcap only
> allowed you to drop privs, not elevate them. Elevating caps
> implies uid 0. By needing setuid root for a capability aware
> program you're depending on uid 0 anyway.
There can be no distinction. Think about it.
The above all happens within the kernel, before any user code runs.
It doesn't matter if the kernel sets all capability values to
something insane, like (uid+gid)/jiffies, as long as they are
correct when the executable actually starts to run.
One might patch the kernel to panic if root ever tries to run
an elfcap executable. This should be a "can't happen" issue.
>> Eh... so should creating a capability-enhanced program under
>> your preferred design. Exceptions must be made in either case,
>> otherwise you couldn't even install the system.
>>
>> See, you had made some claims about suddenly having privileged
>> executables on the system. That just won't happen, except due
>> to errors that affect both elfcap and your preferred design.
>
> No capabilities will be passed on from distributed files if
> they're in the filesystem. Anyone can modify the ELF header.
> (well, anyone with write access, but they need not be privileged)
> They may not be in effect until run by root, but they're still
> there, a time-bomb waiting to happen.
This makes no sense at all. Why do you have root on a system
that is supposed to be using advanced security? Since you do
have root, can't you at least avoid running random trojans?
Never mind the capabilities issue! I want to know how you expect
to avoid a simple "rm -rf /" embedded in one of the trojans
that your root user likes to execute. Root owns a few files,
else you'd have no reason at all to play with the account.
>>> Users should not be able to create setuid files.
>>> Users should not be able to assign capabilities.
>>
>> No problem.
>>
>> With elfcap, inability to create setuid files implies inability
>> to assign capabilities. Even better, inability to create files
>> owned by root also implies inability to assign capabilities.
>> An attacker would have to do both, to the same file, at the same time.
>> If random users can do this, you have a problem even without elfcap.
>
> Elcap implies that someone can assign capabilities to any file
> they have write access for. They aren't active until run by
> root or suid root. I can see a whole slew of symlink or /tmp
> issues comin on...
Look, you need to close the MAJOR security holes first.
Capability bits, in any form, do little good when you
have wide open holes like:
1. random writeable files run by root or suid root
2. root running random files in /tmp
3. root using unsafe file creation in /tmp
Hey, the other system has the SAME "problem" you know:
...aren't active until [...] SOMEBODY ENABLES THE BITS.
You seem to think setuid bits randomly turn on... well,
then filesystem-based capability bits have the same problem.
>>> And the proposals to use ext2 or
>>> XFS to store capabilities in the inode are practical, and secure.
>>
>> 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.
>
> Existing admin scripts will not find elfcap capabilities either.
> It'll find the setuid bit but not capability problems.
Yep, that is good enough for an alert. Assume the worst.
>>> Any filesystem should work with root privilege (well...
>> excluding dosfs).
>>
>> The in-memory system would even work with dosfs.
>
> Only if you ran it as root (no suid bits :))
Nope, the in-memory system is not related to elfcap.
The in-memory system works like this: at some early point during the
boot, before entering secure mode, you load a list of privileged
executables into the kernel. This list indicates what capability
bits each one should have. The kernel then opens each file. Once in
secure mode, the listed files are protected. The files act as if
they had filesystem-based capability bits and the immutable bit.
These files, and only these files, are your privileged executables.
> Here's a question. Is there any reason why we can't do both?
Not "both", but "all three", unless you exclude filesystem hacks.
I have a reason why not: ext2 filesystem stability.
-
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:33 EST