> G. Sumner Hayes writes:
> > Albert Cahalan <acahalan@cs.uml.edu> wrote:
> > > 1. Put capabilities information in the executable header.
> > > 2. Mark the executable setuid root.
> > > 3. Have the kernel check for #1 if #2, and prefer #1 if present.
> >
> > Of course, you've completely busted up security.
> Nope, think about the system a bit more. It isn't so stupid.
> if(setuid){
> if(root_owned && cap_header) use_cap_header();
> else use_setuid_bit();
> }
[snip]
> The above _is_ "real capabilities". It can be more if desired:
> euid = (left as the user)
[snip]
> I_priv = CAP_FOO, CAP_USEFUL_THING, CAP_STUFF
> In the above, I set two of the four UIDs (to different values),
> added 3 extra groups, and changed capabilities.
I think something which causes most people to react negatively to this
scheme is that they have huge issues wrt overloading the longstanding
behavior of 'setuid root == runs with root privs'. I see why Albert wants
to use the root +s bit to mark capabilities-using binaries; it will be easy
to support w/existing file tools, etc. But still, u+s files owned by root
are scary, for good reason -- perhaps we don't like the ramification that
if this system is rebooted to another kernel, or its filesystems NFS
mounted by a box that doesn't support capabilities, whatever. Scary, messy
things will eventually happen in a scheme like that.
So... who says the +s, capability-enabled binaries need to be +x ?
Trying to execute a setuid, non-executable binary on a machine that doesn't
support capabilities should be meaningless and therefore harmless, no?
(unless there some existing significance of u+s, u-x files, like +t on a
file, whether POSIX enforced or simply convention.)
if (is_noexec) {
if(setuid){
if(root_owned && cap_header) use_cap_header();
else
meaningless, EACCES or whatever as usual
else
normal no-capabilities setuid/nonsetuid, whatever
Of course this means that the binary will not run at *all* on non-capable
systems (no pun intended). But from the reactions of Alan, sct, Sumner,
etc, I have a feeling that would be preferred (and I'd agree). If it's
important to make a box that can switch back and forth, you can shell
script around which tools/daemons are fired up, etc.
Hank Leininger <hlein@progressive-comp.com>
-
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/