From: "Maciej Żenczykowski" <zenczykowski@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: linux-security-module@vger.kernel.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mahesh Bandewar <maheshb@google.com>,
Willem de Bruijn <willemb@google.com>,
Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [PATCH] userns: honour no_new_privs for cap_bset during user ns creation/switch
Date: Fri, 22 Dec 2017 02:51:49 +0100 [thread overview]
Message-ID: <CAHo-OoxoTEZuQ0ZXa9a2BnjAv83y0UWC0eqn-ok9hS31LkiiSA@mail.gmail.com> (raw)
In-Reply-To: <87fu83lfw5.fsf@xmission.com>
> Good point about CAP_DAC_OVERRIDE on files you own.
>
> I think there is an argument that you are playing dangerous games with
> the permission system there, as it isn't effectively a file you own if
> you can't read it, and you can't change it's permissions.
Append-only files are useful - particularly for logging.
It could also simply be a non-readable file on a R/O filesystem.
> Given little things like that I can completely see no_new_privs meaning
> you can't create a user namespace. That seems consistent with the
> meaning and philosophy of no_new_privs. So simple it is hard to get
> wrong.
Yes, I could totally buy the argument that no_new_privs should prevent
creating a user ns.
However, there's also setns() and that's a fair bit harder to reason about.
Entirely deny it? But that actually seems potentially useful...
Allow it but cap it? That's what this does...
> We could do more clever things like plug this whole in user namespaces,
> and that would not hurt my feelings.
Sure, this particular one wouldn't be all that easy I think... and how
many such holes are there?
I found this particular one *after* your first reply in this thread.
> However unless that is our only
> choice to avoid badly breaking userspace I would have to have to depend
> on user namespaces being perfect for no_new_privs to be a proper jail.
This stuff is ridiculously complex to get right from userspace. :-(
> As a general rule user namespaces are where we tackle the subtle scary
> things that should work, and no_new_privs is where we implement a simple
> hard to get wrong jail. Most of the time the effect is the same to an
> outside observer (bounded permissions), but there is a real difference
> in difficulty of implementation.
So, where to now...
Would you accept patches that:
- make no_new_priv block user ns creation?
- make no_new_priv block user ns transition?
Or perhaps we can assume that lack of create privs is sufficient, and
if there's a pre-existing user ns for you to enter, then that's
acceptable...
Although this implies you probably always want to combine no_new_privs
with a leaf user ns, or no_new_privs isn't all that useful for root in
root ns...
This added complexity, probably means it should be blocked...
- inherits bset across user ns creation/transition based on X?
[this is the one we care about, because there are simply too many bugs
in the kernel wrt. certain caps]
X could be:
- a new flag similar to no_new_priv
- a new securebit flag (w/lockbit) [provided securebits survive a
userns transition, haven't checked]
- or perhaps a new capability
- something else?
How do we make forward progress?
next prev parent reply other threads:[~2017-12-22 1:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-21 21:06 [PATCH] userns: honour no_new_privs for cap_bset during user ns creation/switch Maciej Żenczykowski
2017-12-21 21:44 ` Eric W. Biederman
2017-12-22 1:03 ` Maciej Żenczykowski
2017-12-22 1:18 ` Eric W. Biederman
2017-12-22 1:51 ` Maciej Żenczykowski [this message]
2017-12-22 14:08 ` Eric W. Biederman
2018-01-03 11:23 ` Christian Brauner
2017-12-22 2:17 ` Aleksa Sarai
2017-12-22 14:21 ` Eric W. Biederman
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=CAHo-OoxoTEZuQ0ZXa9a2BnjAv83y0UWC0eqn-ok9hS31LkiiSA@mail.gmail.com \
--to=zenczykowski@gmail.com \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=maheshb@google.com \
--cc=willemb@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).