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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Mon, 2 Feb 2015 09:18:58 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	Serge Hallyn <serge.hallyn@...ntu.com>
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

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.

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.

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