linux-kernel - Re: [capabilities] Allow normal inheritance for a configurable set of capabilities

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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 2 Feb 2015 18:09:52 +0000
From:	Serge Hallyn <serge.hallyn@...ntu.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Christoph Lameter <cl@...ux.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	Jonathan Corbet <corbet@....net>,
	Aaron Jones <aaronmdjones@...il.com>, Ted Ts'o <tytso@....edu>,
	LSM List <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...uxfoundation.org>,
	"Andrew G. Morgan" <morgan@...nel.org>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set
 of capabilities

Quoting Andy Lutomirski (luto@...capital.net):
> On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn <serge.hallyn@...ntu.com> wrote:
> > A key concept behind posix capabilities is that the privilege comes from
> > both the person and the file being executed.  As you say below basically
> > anything can be executed by the program so that is completely violated.
> >
> > Still, it's not that different from mmapping some arbitrary code and
> > jumping into it whlie retaining caps.
> >
> > If we were to support such a feature, I'm thinking I'd prefer we do
> > it somewhat analogously to the capability bounding set.  Perhaps add a
> > ambient_inh_caps set or something.  Empty by default.  To add caps to it you
> > must have the cap in your permitted set already.  (Ok to do in a user
> > namespace).  Then at exec,
> >
> >         pP' = (X & fP) | (pI & fI) | (pI & pA)
> >
> > pA being your ambient_inh set
> >
> > Not saying this is a good idea necessarily, but worth thinking about.
> 
> This isn't obviously a bad formulation.  We could control pA using some syscall.

My first thought was prctl (since we have PR_CAPBSET_DROP)

> Another formulation would be a single per-user-ns or
> inherited-per-process bit that sets fI to the full set regardless of
> file caps.  Dealing with the file effective bit will be an added
> complication, as will dealing with setuid binaries.
> 
> How many of you will be at LSF/MM?  This might be a decent topic.

I'm not scheduled to be there.
--
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/