(I've cc'ed Ted T'so, because he's credited as a contributor in the
linux-privs docs, and from what I've read from him he knows more about
capabilities support than any of us; if I make a mis-statement, he can
correct me)
On Wed, 14 Apr 1999, Pavel Machek wrote:
> Hi!
[snip stickybit+immutable desc.]
> Too bad this is not option: immutable bit is ext2 specific. These are
> not only nfs problems you would have to face: there are also umsdos
> and tar and coda and ... problems.
I know that this scheme breaks over nfs and coda, but it can be
made to work just fine with cp, tar, et. al.
Now, I assume that our goal in putting caps in the elf headers is
to give us true capabilities support for elf binaries. At least, that is
_my_ goal. If that is _your_ goal as well, then here I will prove that
setuid0 will not work at all, even on a local ext2 fs. It has to do with
the behavior of the inheritable sets for processes and binaries, and I
believe you haven't done your homework in reading up on how a new process
gets it's capabilities. To quote from the 'linux-privs' doc:
"Following an exec(), the process' Permitted set is constructed from the
following combination of the former, and invoked, file's capability sets:
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. This also means than, when exec'ing
a file, the permitted set of the current process doesn't matter at all,
and the inheritable set is where it derives all it's power.
The complete document can be browsed at:
http://www1.us.kernel.org/linux/libs/security/linux-privs/doc/linux-privs.html/linux-privs.html
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.
- With the stickable solution, the file is marked +t and immutable, which
is a priviledged operation but otherwise harmless; with setuid0, you have
to make chown(1) setuid root! If you _don't_ require setuid0 on binaries
with an inheritable set, you open yourself to normal users being able to
create binaries that can inherit all the caps from it's parent process.
Similar arguments apply to tar, cp ...
Now, as to the remote-fs weakness of my solution; I don't know of
any good solution. If nfs can return extended attributes (ok, sticky bit
is set, but is immutable set as well?) then it can at least be made to
work over nfs to a Linux-ext2 export. I don't know nfs well enough to
know if this is possible.
Some have argued that, if you're running a system with the
capabilities-based (and non UNIX-like) security model, you shouldn't be
executing binaries over nfs anyway.
I argue that when we have true capabilities in the fs (which may
be coming), they will not only break remote fs's but all current tools,
such as tar; the stickable solution can be made to work fine by setting
the correct inheritable bits in tar.
I think the problem I've pointed out is a show-stopper for the
setuid0 solution.
> Pavel
>
> PS: Sorry, immutable bit just is not correctly supported these days.
What do you mean by this, btw?
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/