Messages in this thread | | | Date | Wed, 14 Apr 1999 09:30:08 -0400 (EDT) | From | "David L. Parsley (lkml account)" <> | Subject | Re: caps in elf headers: use the sticky bit! |
| |
Hi Pavel,
(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/
| |