lkml.org 
[lkml]   [1999]   [Apr]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectcapabilities in elf headers: next (final?) itteration
Hi all,
I think I've got the 'Right Solution' (tm) to putting caps in elf
headers in the most appropriate way (i.e., the UNIX way):

1) if capability info is in the fs, use that and ignore cap elf headers

2) otherwise, if the executable is marked setuid root in the fs, use all
of forced, permitted and inheritable caps in the elf headers. This is for
binaries which were formerly full-fledged setuid root; i.e., had full
caps.

3) otherwise, ignore 'forced' caps in headers, but apply the permitted and
inheritable bits. This way, if the prog is run by root (or a parent with
full caps) it can be restrained, and any process running with elevated
caps can be further restrained by anyone with write access to the
executable (but can otherwise accomplish whatever the raised caps would
allow).

Notes, thoughts, consequences and questions::

- 'setuid root' binaries should probably also allow setting of
r/euid in the cap headers for maximum flexibility; r/euid values should be
ignored w/o 'setuid root'.
- there should be no need to cripple the binary for older kernels,
since older kernels should ignore all cap info, and the situation is no
different from before. i.e., this system doesn't require executables be
made setuid root that weren't setuid root in the first place.
- checking for the presence of caps in the executable should be
_fast_ since under this scheme _every_ executable will be checked for
caps. Of course, if the calling process has _no_ caps raised (quick &
easy check), caps can be ignored for non-'setuid root' binaries.

And now for the BIG one:

- having 'root' r/euid is still powerful, since under this scheme
root can create & modify setuid binaries and give them full privs (even
privs that the current root-owned process doesn't have!). Thus, the
ability to mark a file 'setuid root' or modify a file which is already
'setuid root' should be another capability added. With this added
capability, you can completely take away the magic from a root-owned
process and bring us _very_ close to the ideal situation where root isn't
special and users may have elevated caps.

A big thanks to Ingo Molnar, caffeine and nicotein for putting my mind on
this track; however, this scheme currently seems so perfect, that I wonder
if I may have introduced a glitch by 'overclocking my CPU'. ;-)

thoughts?

- --
David L. Parsley
Network Specialist
City of Salem Schools

Note to RGooch: I would have cc'ed you, too, but I'm too lazy to fool with
the magic number bit.


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

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.035 / U:0.160 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site