[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150224154715.GA20682@mail.hallyn.com>
Date: Tue, 24 Feb 2015 09:47:15 -0600
From: "Serge E. Hallyn" <serge@...lyn.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: Serge Hallyn <serge.hallyn@...ntu.com>,
Christoph Lameter <cl@...ux.com>,
Serge Hallyn <serge.hallyn@...onical.com>,
Andy Lutomirski <luto@...capital.net>,
Aaron Jones <aaronmdjones@...il.com>, Ted Ts'o <tytso@....edu>,
linux-security-module@...r.kernel.org, akpm@...uxfoundation.org,
"Andrew G. Morgan" <morgan@...nel.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>,
Austin S Hemmelgarn <ahferroin7@...il.com>,
Markku Savela <msa@...h.iki.fi>,
Jarkko Sakkinen <jarkko.sakkinen@...ux.intel.com>,
linux-kernel@...r.kernel.org, linux-api@...r.kernel.org,
Michael Kerrisk <mtk.manpages@...il.com>,
Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH] capabilities: Ambient capability set V1
On Mon, Feb 23, 2015 at 11:19:29PM -0600, Serge E. Hallyn wrote:
> On Mon, Feb 23, 2015 at 06:15:53PM +0000, Serge Hallyn wrote:
> > Quoting Christoph Lameter (cl@...ux.com):
> > > On Mon, 23 Feb 2015, Serge E. Hallyn wrote:
> > >
> > > > > I do not see a problem with dropping privilege since the ambient set
> > > > > is supposed to be preserved across a drop of priviledge.
> > > >
> > > > Because you're tricking the program into thinking it has dropped
> > > > the privilege, when in fact it has not.
> > >
> > > So the cap was dropped from the cap perm set but it is still active
> > > in the ambient set?
> >
> > Right, and the legacy program doesn't know to check the new set.
>
> we've been assuming the ambient set must be like fP. is there any
> reason why it doesn't suffice for them to be or'ed with fI instead at
> exec? then the bits would need to ne in pI. this might sufice for
> Christoph's use case, as pI will generally not change. and for programs
> that really care, they can check pI.
The other way to look at it then is that it's basically as though the
privileged task (which has CAP_SETFCAP) could've just added fI=full to
all binaries on the filesystem; instead it's using the ambient set
so that the risk from fI=full is contained to its own process tree.
--
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/
Powered by blists - more mailing lists