>>> header scenario? I see. So its not really a full principle of least
>>> privilege implementation.
>>
>> Well, we get the same effect. We let setuid-root raise everything before
>> the header drops capabilities back down. This is just fine as long as you
>> don't let root log in.
>
> But only safely in a "drop privileges only" security model. Correct?
No. Since you don't let root log in, anything owned by UID 0 is safe.
You can even leave root all-powerful for startup-script compatibility.
(Irix has capabilities, but it leaves root all-powerful. We can do that.)
> And your basing everything on the suid bit.
Either setuid-root or some other filesystem-specific feature specified at
mount time. One might trust all files on read-only media.
> You should at least
> protect setting of the suid bit, with a capability.
Yes. I'd like to see separate capabilities for:
a. chown file to a UID held by the current process
b. chown file to any non-zero UID
c. chown file to 0
Then add "chown file from" and "set setuid on" versions of the above.
> I've been putting some thought into the concept of a "protected UID",
> whose files cannot be read/write/search even if you manage to become his
> UID without capabilities say CAP_PROTECTED_READ, CAP_PROTECTED_WRITE, or
> CAP_PROTECTED_SEARCH. This would be very useful on a system such
> as linux that supports privileges but not mandatory access control,
> because if you manage to buffer overflow a setuid 0 capability
> enhanced program, even though you may get no privileges, you still
> could edit his files (passwd, shadow, ...).
This problem is hard to solve. I suggest something more like "true"
or "real" capabilities. Either the executable has a list of files
that it can access, or the files have lists of executables that can
access them. I suggest supporting both, since the optimal choice for
performance and storeage space will vary.
>> Putting everying in the inode would work, but it breaks compatibility.
>
> Well ext3 could store it in the inode, with the new kernels ignoring
> privileges if you disable full-blown capabilities. That way distributions
> could be built as "vanilla" linux or as "trusted" linux.
This choice depends on what your goal is. Do you want to create insanely
secure systems that only an NSA sysadmin could handle? Do you want to
help protect newbie admins who only weakly understand permissions?
You must have some goal in mind. Here is mine:
Create security enhancements that Red Hat can enable by default.
This means NFS support is important. Newbie admins should not need to
worry about anything, but expert admins should have some flexibility.
It should be possible to admin the system without a root account.
Even better, root daemons and normal setuid-root executables should not
be needed. Normal software (Oracle, BRU, Stronghold) should run.
It would also be very nice to meet C2 or B1, shutting up M$ and *BSD.
> I think that in the interim, capabilities that are included in ELF and
> that only lower privileges are a definitely a good thing. Of course
> provided the files are adequately protected, and someone can't find a way
> to delete/add the capabilities and maintain runability of the process.
Linux drops the setuid bit when an executable is modified.
> (NOTE: causing a program to run with too few privileges could
> cause a denial of service.)
This is why I keep suggesting an extra set of capability bits that
specifies what the minimum requirement is. Execution should just fail.
(maybe log the attempt too)
-
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/