Re: caps in elf headers: use the sticky bit!

Albert D. Cahalan (acahalan@cs.uml.edu)
Tue, 13 Apr 1999 01:18:07 -0400 (EDT)


David L. Parsley (kparse@salem.k12.va.us)
> On Sun, 11 Apr 1999, Pavel Machek wrote:
>
>> You do not want this kind of support in kernel. Believe me.
>> Better use setuid0 as marker (those are already immutable) and
>> userspace suid program which implements your CAP_SETFCAP.
>
> This applies just as well to the sticky bit solution; if it's not
> feasible to have the kernel check the caps in the file when setting
> the cap flag, you could still have a userspace util that did all
> the real work. Good idea!

I'm doing that just now.

The code is privileged (currently setuid-root), so it takes a long time
to write. Sometimes it looks like I have more error checking code than
productive code.

Policy is determined by a config file. Liberal admins can let users
make setuid-root executables. :-)

Files become setuid-root. The executable header gets mangled, unless the
executable is already setuid-root.

Currently, you would use a specification file like this:

^^TypeA^^
fP CAP_SYS_RESOURCE CAP_SYS_RAWIO / Room for 128 bits, but only
fE / 64 can be used with existing code.
fI CAP_NET_BROADCAST
RUID RUID
EUID RUID
SUID RUID
FUID RUID
RGID RGID
EGID games
SGID uucp
FGID RGID
groups games uucp mail

I could add some sort of extended access control to that. I could add
a minimum capability requirement, so that execution fails if the
post-exec capabilities are not enough to complete execution.

There is also a shortcut method that lets you specify capabilities on the
command line. (all 3 fields get the same content -- reasonable?)

I've saved ELF hacking for last. Hopefully I won't need to write my own
ELF support code. (Help!) I don't trust libraries too much, since I don't
want to see my code posted to Bugtraq.

As usual, all code is under the LGPL.

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