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/