From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Christoph Lameter <cl@linux.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Jonathan Corbet <corbet@lwn.net>,
Aaron Jones <aaronmdjones@gmail.com>, "Ted Ts'o" <tytso@mit.edu>,
LSM List <linux-security-module@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linuxfoundation.org>,
"Andrew G. Morgan" <morgan@kernel.org>
Subject: Re: [capabilities] Allow normal inheritance for a configurable set of capabilities
Date: Mon, 2 Feb 2015 18:09:52 +0000 [thread overview]
Message-ID: <20150202180952.GF24351@ubuntumail> (raw)
In-Reply-To: <CALCETrVNgwyw37g+RGj1cZG2cVRPwucdDCC=WmiB6v+dUO7nyA@mail.gmail.com>
Quoting Andy Lutomirski (luto@amacapital.net):
> On Mon, Feb 2, 2015 at 9:12 AM, Serge Hallyn <serge.hallyn@ubuntu.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.
next prev parent reply other threads:[~2015-02-02 18:10 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-02 16:21 [capabilities] Allow normal inheritance for a configurable set of capabilities Christoph Lameter
2015-02-02 17:12 ` Serge Hallyn
2015-02-02 17:18 ` Andy Lutomirski
2015-02-02 18:09 ` Serge Hallyn [this message]
2015-02-03 15:16 ` Christoph Lameter
2015-02-03 15:23 ` Christoph Lameter
2015-02-03 15:55 ` Serge E. Hallyn
2015-02-03 17:18 ` Christoph Lameter
2015-02-03 17:26 ` Serge E. Hallyn
2015-02-04 15:15 ` Andrew G. Morgan
2015-02-04 15:50 ` Christoph Lameter
2015-02-04 15:56 ` Serge E. Hallyn
2015-02-04 16:12 ` Andrew G. Morgan
2015-02-04 16:34 ` Andy Lutomirski
2015-02-04 16:54 ` Andrew G. Morgan
2015-02-04 17:34 ` Serge E. Hallyn
2015-02-04 18:12 ` Christoph Lameter
2015-02-04 16:43 ` Christoph Lameter
2015-02-04 16:27 ` Andy Lutomirski
2015-02-05 0:34 ` Serge E. Hallyn
2015-02-05 15:23 ` Serge E. Hallyn
2015-02-25 21:50 ` Pavel Machek
2015-02-25 23:59 ` Christoph Lameter
2015-02-26 12:27 ` Pavel Machek
2015-02-27 20:15 ` Andy Lutomirski
2015-02-27 20:48 ` Pavel Machek
2015-02-27 20:56 ` Andy Lutomirski
2015-02-27 22:47 ` Pavel Machek
2015-02-02 17:54 ` Casey Schaufler
2015-02-02 18:08 ` Serge Hallyn
2015-02-02 18:47 ` Mimi Zohar
2015-02-02 19:05 ` Austin S Hemmelgarn
2015-02-02 20:35 ` Casey Schaufler
2015-02-03 16:04 ` Serge E. Hallyn
2015-02-02 19:00 ` Casey Schaufler
2015-02-05 0:20 ` Serge E. Hallyn
2015-02-02 20:37 ` Andy Lutomirski
2015-02-02 20:54 ` Casey Schaufler
2015-02-03 15:51 ` Serge E. Hallyn
2015-02-03 16:37 ` Casey Schaufler
2015-02-03 17:28 ` Serge E. Hallyn
2015-02-03 17:50 ` Casey Schaufler
2015-02-03 19:45 ` Christoph Lameter
2015-02-03 20:13 ` Andy Lutomirski
2015-02-03 23:14 ` Christoph Lameter
2015-02-03 23:17 ` Andy Lutomirski
2015-02-04 2:27 ` Christoph Lameter
2015-02-04 6:05 ` Markku Savela
2015-02-04 13:17 ` Christoph Lameter
2015-02-04 13:41 ` Markku Savela
2015-02-04 14:56 ` Jarkko Sakkinen
2015-02-03 15:17 ` Christoph Lameter
2015-02-03 15:40 ` Casey Schaufler
2015-02-03 15:46 ` Serge E. Hallyn
2015-02-03 17:19 ` Christoph Lameter
2015-02-03 17:29 ` Serge E. Hallyn
2015-02-25 21:50 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150202180952.GF24351@ubuntumail \
--to=serge.hallyn@ubuntu.com \
--cc=aaronmdjones@gmail.com \
--cc=akpm@linuxfoundation.org \
--cc=cl@linux.com \
--cc=corbet@lwn.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=morgan@kernel.org \
--cc=serge.hallyn@canonical.com \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.