linux-kernel - Re: [RFC] Capabilities still can't be inherited by normal programs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALQRfL67LX5owxo=SMuRNAm1Jds53zY-moLpXE=wCTF4Epu4_w@mail.gmail.com>
Date:	Sun, 2 Dec 2012 09:21:41 -0800
From:	"Andrew G. Morgan" <morgan@...nel.org>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	Kees Cook <keescook@...omium.org>,
	James Morris <james.l.morris@...cle.com>,
	Eric Paris <eparis@...hat.com>,
	"Serge E. Hallyn" <serge@...onical.com>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs

There is a fairly well written paper ;-) explaining how things are
supposed to work:

  http://ols.fedoraproject.org/OLS/Reprints-2008/hallyn-reprint.pdf

The inheritable set is not intended to work the way you seem to want.
Naive inheritance like that is quite explicitly the opposite of what
was designed.

Cheers

Andrew

On Sat, Dec 1, 2012 at 7:04 PM, Andy Lutomirski <luto@...capital.net> wrote:
> 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/