I'd like to be able to run programs (like bash!) as nonroot but with some capabilities granted. After all these years, it's almost, but not quite, possible. This is because the transition rule (if root isn't involved or NOROOT is set) is pP' = (pB' & fP) | (pI' & fI), and, when execing a program without vfs caps set, fI = 0. I want to set PR_SET_KEEPCAPS, setuid away from root, set some capability as inheritable, and exec something. That capability stays inheritable, but it doesn't end up permitted. Oops.
(There's another alarming thing that happens -- programs end up with capability bits that are inheritable but not permitted. I'd like to change cap_bprm_set_creds to clear all inheritable bits that don't end up in the final permitted set to minimize confusion. Of course, this *could* (but seems unlikely to) trigger security bugs.) The obvious but scary fix is to make everything act like fI = <all caps> if vfs caps aren't set. It's not immediately obvious why this would be bad: no task has any inheritable capabilities by default. Something like the sendmail bug is unlikely here -- this change would give *more* caps, not fewer, and it could be done in such a way that setuid binaries don't inherit caps. A less scary way would be to make it opt-in: set a securebit if you want default capability inheritance. This requires CAP_SETPCAP, which seems to be shorthand for "allow me to shoot myself in the foot". Sensible programs might set no_new_privs when they set this securebit. An even less scary way would be to require a new securebit *and* no_new_privs. Any suggestions? I'm happy to write patches, but I'd rather not cook up ten patches and have this get stuck in limbo for years. For some rationale: I want to write a program that has cap_net_raw permitted as a file capability. That program will do some checks and then invoke tcpdump. I can't do this: tcpdump can't inherit capabilities into its permitted set unless I set the cap_net_raw inheritable bit on it. --Andy P.S. The get_file_caps code is gross. Whatever the outcome of this discussion, I'll submit a patch to clean it up, and I'll probably add a file to Documentation/security for good measure. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
