Messages in this thread | | | Date | Thu, 23 Oct 2003 12:46:16 -0400 | From | Theodore Ts'o <> | Subject | Re: posix capabilities inheritance |
| |
On Tue, Oct 21, 2003 at 06:26:45AM -0500, Michael Glasgow wrote: > I wrote a simple setuid-root wrapper which sets some capabilities, > gives up all other privs, and and then execs a shell. I was hoping > to use this wrapper as a login shell so that I could have a user > log in interactively with a small subset of elevated privileges. > > Unfortunately after looking over the capabilities code in the 2.4 > kernel, it would appear that this is not currently possible, and > my wrapper cannot work without filesystem support for capabilities. > And even then, I'd have to set each file's inheritable flag for the > capabilities I want on every executable that I am likely to run, > including the shell. Am I mising something, or is this an accurate > description?
No, you're not missing anything.
What happened here is that originally there was a security vulnerability caused by an a badly desgined attempt to take advantage of capabilities without filesystem support. In order to fix it, the patch took a very conservative path, which completely disabled the use of selective capability inheritance. (Capabilities are still useful, but only in setuid root programs that selectively drop unneeded capabilities --- still in my opinion the best way to use capabilities, BTW).
> As an interim workaround, how about assuming all capabilities are > inheritable in fs/exec.c:prepare_binprm, i.e. instead of > cap_clear(bprm->cap_inheritable), call cap_set_full() ??? I don't > think this would break anything, and it would make capabilities a > lot more useful until we get fs support merged in.
I agree this is safe, and allows the use of your setuid wrapper script. The one reason why I think it's better to modify programs is that it's too easy for individual system administrators to screw up the configuration used by your wrapper script, and accidentally introduce a security vulnerability into their system. It's dangerous to give a program some capability (or reduce the capability given to a program designed to be setuid) without examining the source code and being clueful. So by making the program setuid and editing the source code to add an explicit capability drop in the program is much, much safer compared to having a random system administrator to edit a config file and trust that he or she does so correctly.
- Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |