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]

Date:	Wed, 5 Dec 2012 16:20:40 -0600
From:	Serge Hallyn <serge.hallyn@...onical.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>,
	"Andrew G. Morgan" <morgan@...nel.org>,
	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>,
	Markku Savela <msa@...h.iki.fi>
Subject: Re: [RFC] Capabilities still can't be inherited by normal programs

Quoting Andy Lutomirski (luto@...capital.net):
> On Wed, Dec 5, 2012 at 1:05 PM, Serge Hallyn <serge.hallyn@...onical.com> wrote:
> > Quoting Andy Lutomirski (luto@...capital.net):
> >> On Tue, Dec 4, 2012 at 5:54 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> >> > Quoting Andy Lutomirski (luto@...capital.net):
> >> >> >> d) If I really wanted, I could emulate execve without actually doing
> >> >> >> execve, and capabilities would be inherited.
> >> >> >
> >> >> > If you could modify the executable properties of the binary that has
> >> >> > the privilege to wield a privilege then you are either exploiting an
> >> >> > app bug, or doing something the privileged binary has been trusted to
> >> >> > do.
> >> >>
> >> >> That's not what I mean.  I would:
> >> >>
> >> >> fork()
> >> >> munmap everything
> >> >> mmap ld.so
> >> >> set up a fake initial stack and the right fd or mapping or whatever
> >> >> just to ld-linux.so
> >> >>
> >> >> That's almost execve, and privilege inheritance works.
> >> >
> >> > But of course that is why you only want to fill fI on programs you trust
> >> > not to do that.  What you are arguing is that you want to give fI on
> >> > programs you don't trust anyway, and so heck why not just give it on
> >> > everything.
> >> >
> >>
> >> Huh?  I'd set fP on a program I expect to do *exactly* that (or use
> >> actual in-kernel capability inheritance, which I would find vastly
> >> more pleasant).  If I give a program a capability (via fP or fI & pI),
> >> then I had better trust it not to abuse that capability.  Having it
> >> pass that capability on to a child helper process would be just fine
> >> with me *because it already has that capability*.
> >>
> >> The problem with the current inheritance mechanism is that it's very
> >> difficult to understand what it means for an fI bit or a pI bit to be
> >> set.  Saying "set a pI bit using pam if you want to grant permission
> >> to that user to run a particular program with fI set" is crap -- it
> >> only works if there is exactly one binary on the system with that bit
> >> set.  In any case, a different administrator or package might use it
> >> for something different.
> >>
> >> Suppose I use the (apparently) current suggested approach: I install a
> >> fI=cap_net_raw copy of tcpdump somewhere.  Then I write a helper that
> >> has fP=cap_new_raw and invokes that copy of tcpdump after appropriate
> >> validation of parameters.  All is well.
> >
> > Since you're writing a special helper, you can surely have it validate
> > the userid and make it so the calling user doesn't have to have
> > cap_net_raw in pI?
> 
> I can and did.

Oh, oops, I mis-understood what you meant was the problem.

Yup, that is a real limitation.

Yes, with the posix file caps you will be disappointed unless you see
pI=X as "this user may run any program which is Inh-trusted with X" and
fI=X as "this program may be run with X by any user Inh-trusted with X".

It almost makes me want to say that there should be an execve-analogue
to prctl(PR_SET_KEEPCAPS), which says caps will remain unchanged for one
execve.  Or perhaps an intermediate securebits state between
!SECBIT_NOROOT and SECBIT_NOROOT, which automatically transitions after
the first execve to SECBIT_NOROOT.

> The mere presence of a cap_net_raw+i tcpdump binary is more or less
> equivalent to saying that users with cap_net_raw in pI can capture
> packets.  I've just prevented pI=cap_net_raw from meaning anything
> less than "can capture packets".  So I think we should bite the bullet
> and just let programs opt in (via some appropriately careful
> mechanism) to real capability inheritance.

By real you mean more precise.  I think it'd be very interesting to get
together with Markku and learn more from the N9 experiment!

Markku, are there any post-mortem analysis papers we can read for
starters?  Andy would not be trying to restrict root in general, so
the ramification you cited may not necessarily be relevant.

-serge
--
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/