Messages in this thread | | | Subject | RE: Capabilities in fs vs. exe | Date | Thu, 15 Apr 1999 18:55:53 -0500 | From | Evan Jeffrey <> |
| |
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/
| |