Messages in this thread | | | Date | Wed, 14 Apr 1999 22:41:44 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
Hi Albert,
On Wed, 14 Apr 1999, Albert D. Cahalan wrote:
> > David L. Parsley writes: > > > (I've cc'ed Ted T'so, because he's credited as a contributor in the > > OK, me too. (is this desired or annoying?)
Well, I think Ted freely exercises his right to ignore us. ;-)
> > > pP' = fP | ( fI & pI ). > > > > Or in other words, the process' permitted set becomes the combination of > > the permitted set of the exec()'d file and those inheritable capabilities > > of the exec()ing file that are also inheritable by the file." > > > > This means that, not only is the permitted set important for a > > file (which works fine under setuid0), but also important is the > > inheritable set; i.e., setting the inheritable set should be a priviledged > > operation, and in the absence of permitted or inheritable sets, a new file > > should execute with no capabilities. > > There is a difference between "no capabilities" and "undefined capabilities". > The kernel can do whatever is best for the undefined case, perhaps under > the influence of a configuration option.
Most compatible way is: inheritable=all, effective=all; most paranoid way is: inheritable=none, effective=none; I'd say go for compatible, but possibly cripple some binaries. This should be configurable, however.
> > Let's consider the chown(1) program, for a nice, concrete example. > > > > - CAP_CHOWN is the capability required for changing the owner of a file. > > > > - The CAP_CHOWN cap should be flagged in the inheritable set of the chown > > binary, and if it's also flagged in the inheritable set of the parent > > process, chown(1) should be capable of setting the file owner. > > This is getting really silly of course. It means you have to give > special rights to emacs, dd, perl, patch, gzip, tar, ln, gcc...
Solved above.
> > If you really are that insane, you can have a config option for it. > I doubt that it is helpful to require that every tool have bits set. > > > I think the problem I've pointed out is a show-stopper for the > > setuid0 solution. > > Eh, what problem?
The problem that setting inheritable bits is a non-priviledged operation under the setuid0 scheme, and there is a LOT of power in the inheritable bits. You are left wide open to trojan binaries, but a paranoid sysadmin (or distribution maintainer) can lock a system down _tight_ with the stickybit/immutable solution. _Without_ recompiling all the tools. (assuming, that is, that you're making progress with your cap-setting utility ;-)
There are worse problems, though; see my latest treatise to Pavel for a much better named(8) example. (you should have it in 2 minutes or less ;-)
cheers, David
- -- David L. Parsley Network Specialist City of Salem Schools
- 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/
| |