lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRE: Capabilities in fs vs. exe
Date
From

Given that I don't know much about capabilites systems, feel free to flame
me if this is stupid, but it sounds like this would work:

Put capability sets in both ELF headers and, optionally in FS metadata.

Capabilities in ELF headers are "negative capabilites" -- they can only
subtract from a processes' capability.

FS metadata can add or remove capabilites.

Every userid has a mapping to a capability set. This can be either zero->
all caps, everything else -> "normal access" (for a traditional UNIX system),
every uid -> "normal access", or something more complicated, managed by a
security daemon, which the kernel could query when necessary.

the suid bit means "change user id, and aquire default permissions for that
user"

On exec, first, drop all permissions that aren't supposed to survive exec.
Then, processss the suid bit and possible filesystem capability info,
and grant all of those. Then, read the elf header and drop any permissions
the header says to drop.

Now. to build a capability enhanced system while mostly remaining compatable,
give root uid 0, and all caps by default, then add capability headers to suid
programs and system daemons. suid programs will start up as root, drop caps
they don't need, and run as normal. System daemons will be executed from
init/inetd with all caps, but not necessarily root, and will drop caps they
don't need, then start up.

User jondoe can also make a binary suid to him, but with caps set to drop
all unnecessary caps if it, say, needed to be able to read all of his files,
but not write to any of them.

To build a more flexible system, set the kernel to not give uid 0 all caps
by default (but init still starts with all caps, of course). Now, suid root
just means switch to user 0, with no extra caps, and unless FS metadata is
present, it is impossible to gain caps.

For a solution more like the first, yet with seperate administrators and
access levels, a security daemon could be implemented that would give binaries
suid to a given user certain capabilities (some of which could be dropped from
the header info).

In either case, non suid binaries can be made to drop capabilities they don't
need just by setting the header.

This will also prevent any possibility of hacked binaries being given extra
caps unless you are trusting an NFS server which doesn't handle suid bits
correctly, in which case you might as well give up.

This leaves an issue of when to drop caps when doing a setuid(): ie. inetd
doesn't want to drop caps before starting a daemon that doesn't run as root,
since the cap headers should take care of that, but login must drop all caps
that the user doesn't get before starting a shell. login is easy to fix, but
the secuity implications of programs which do a setuid() assuming they will
lose capabilities must be considered. This is essentially a non-issue if the
FS has capability support, but might be a problem otherwise. It doesn't
look insurmountable, though.

I am interested in hearing any realistic situations this can't handle. It
seems that it avoids overloading the sticky bit *and* the suid bit for the
most part, while allowing reasonably good security without a capability aware
FS, yet allows the associated flexibility if such support is present.

Evan Jeffrey

-
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.031 / U:0.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site