Date: Tue, 21 May 2024 17:45:07 -0700
From: Jonathan Calmels <jcalmels@...0.net>
To: John Johansen <john.johansen@...onical.com>
Cc: Jarkko Sakkinen <jarkko@...nel.org>, 
	Casey Schaufler <casey@...aufler-ca.com>, brauner@...nel.org, ebiederm@...ssion.com, 
	Luis Chamberlain <mcgrof@...nel.org>, Kees Cook <keescook@...omium.org>, 
	Joel Granados <j.granados@...sung.com>, Serge Hallyn <serge@...lyn.com>, 
	Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>, 
	David Howells <dhowells@...hat.com>, containers@...ts.linux.dev, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-security-module@...r.kernel.org, keyrings@...r.kernel.org
Subject: Re: [PATCH 0/3] Introduce user namespace capabilities

On Tue, May 21, 2024 at 07:45:20AM GMT, John Johansen wrote:
> On 5/21/24 07:12, Jarkko Sakkinen wrote:
> > On Tue May 21, 2024 at 4:57 PM EEST, John Johansen wrote:
> > > > One tip: I think this is wrong forum to present namespace ideas in the
> > > > first place. It would be probably better to talk about this with e.g.
> > > > systemd or podman developers, and similar groups. There's zero evidence
> > > > of the usefulness. Then when you go that route and come back with actual
> > > > users, things click much more easily. Now this is all in the void.
> > > > 
> > > > BR, Jarkko
> > > 
> > > Jarkko,
> > > 
> > > this is very much the right forum. User namespaces exist today. This
> > > is a discussion around trying to reduce the exposed kernel surface
> > > that is being used to attack the kernel.
> > 
> > Agreed, that was harsh way to put it. What I mean is that if this
> > feature was included, would it be enabled by distributions?
> > 
> Enabled, maybe? It requires the debian distros to make sure their
> packaging supports xattrs correctly. It should be good but it isn't
> well exercised. It also requires the work to set these on multiple
> applications. From experience we are talking 100s.
> 
> It will break out of repo applications, and require an extra step for
> users to enable. Ubuntu is already breaking these but for many, of the
> more popular ones they are shipping profiles so the users don't have
> to take an extra step. Things like appimages remain broken and wil
> require an approach similar to the Mac with unverified software
> downloaded from the internet.
> 
> Nor does this fix the bwrap, unshare, ... use case. Which means the
> distro is going to have to continue shipping an alternate solution
> that covers those. For Ubuntu atm this is just an extra point of
> friction but I expect we would still end up enabling it to tick the
> checkbox at some point if it goes into the upstream kernel.

I'm not sure I understand your point here and how this relates to xattrs.
This patchset has nothing to do with file capabilities. The userns
capability set is purely a process based capability set and in no way
influenced by file attributes.

> > This user base part or potential user space part is not very well
> > described in the cover letter. I.e. "motivation" to put it short.
> > 
> yes the cover letter needs work

Yes, it's been mentioned several times already.
While not in the cover letter, the motivation is stated in the first
patch and provides several references to past discussions on the topic.

This is nothing new, this subject has been contentious for years now and
discussed over and over on these lists (Eric would know :)). As
mentioned in the patch also, this recently warranted the inclusion of
new LSM hooks.

But again, I wrongfully assumed that this problem was well understood
and still relatively fresh, that's my bad.

> > I mean the technical details are really in detail in this patch set but
> > it would help to digest them if there was some even rough description
> > how this would be deployed.
> > 
> yes

Yes, this was purposefully left out so as not to influence any specific
implementation. There is a mention of where this could be done (i.e.
init, pam), but at the end of the day, this is going to depend on each
use case.
Having said that, since it appears to be confusing, maybe we could add
some of the examples I sent out in this thread or the other ones.

I want to reiterate that this is a generic capability set, this is not
magic switch you turn on to secure the whole system.
Its implementation is going to vary across environments and it is going
to be dictated by your threat model.

For example, John's threat model of securing a multi-user Ubuntu Desktop
is going to be very different than say securing a server where all the
userspace is fixed and known.
The former might require additional integration with the LSM subsystem.
Thankfully, this patch should synergize well with it.

Fundamentally, and at its core, it's very simple. Serge put it nicely:

> If you want root in a child user namespace to not have CAP_MAC_ADMIN,
> you drop it from your pU.  Simple as that.

>From there, you can imagine any integration you want in userspace and
ways to enforce your own policies.

TLDR, this is a first step towards empowering userspace with control
over capabilities granted by a userns. At present, the kernel does not
offer ways to do this. By itself, it is not a comprehensive solution
designed to thwart threat actors. However, it gives userspace the option
to do so.

Powered by blists - more mailing lists