Re: Subject: Re: ext3 to include capabilities?

Albert D. Cahalan (acahalan@cs.uml.edu)
Fri, 2 Apr 1999 13:39:35 -0500 (EST)


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();
}

> On my machine
> there's a crypto-daemon that wants to mlock() some RAM. I have a little
> setuid wrapper to give it mlock capability on 2.2.x, but I'm not about
> to let it run with full root privs -- under 2.0.x (or whenever it can't

My system does not give full root privs.

> mlock()), it prints a detailed warning and lets the user decide whether
> the risk is worth the convenience of not typing passwords constantly.
> The whole point of capabilities is that you only trust a daemon with
> some small set of powers -- promoting it to full root privs is downright
> dangerous.

Yep - that is what my system offers.

> Requiring a setuid wrapper as I have now is pretty bogus.
>
> Also, explain how I do each of the following in your scheme:
> 1. Make an executable that runs with UID 0 but no capabilities.

Use the setuid bit as normal, if it is not disabled. If you did disable
the setuid bit, you might still allow it via the header. If you disable
that too, then you obviously don't want a UID 0 executable.

> 2. Make an executable that runs with exec'rs UID and capabilities.

Fill in headers that mean "normal UID with capabilities", then make
the executable setuid-root. It will NOT run as root.

> 3. Make an executable that runs with UID 0 and capabilities.

Fill in headers that mean "UID 0 with capabilities", then make the
executable setuid-root.

> with real capabilities in the fs:

The above _is_ "real capabilities". It can be more if desired:

euid = (left as the user)
ruid = (left as the user)
suid = sybase
fsuid = mail
extragroups = foo, bar, baz
P_priv = CAP_FOO, CAP_BAR, CAP_BAZ
E_priv = CAP_FOO, CAP_WHATEVER, CAP_XYZ
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.

-
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/