[RFC] Capabilities still can't be inherited by normal programs

From: Andy Lutomirski <luto@amacapital.net>
To: linux-kernel@vger.kernel.org, linux-security-module@vger.kernel.org
Cc: Kees Cook <keescook@chromium.org>,
	James Morris <james.l.morris@oracle.com>,
	Eric Paris <eparis@redhat.com>,
	"Andrew G. Morgan" <morgan@kernel.org>
Subject: [RFC] Capabilities still can't be inherited by normal programs
Date: Sat, 1 Dec 2012 19:04:56 -0800	[thread overview]
Message-ID: <CALCETrVQxPDfU83-LUWrf330wOBbSsMvKdFXMR3CL4LmDvyfMw@mail.gmail.com> (raw)

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.