Date: Fri, 31 May 2024 00:43:26 -0700
From: John Johansen <john.johansen@...onical.com>
To: Jonathan Calmels <jcalmels@...0.net>
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 5/21/24 17:45, Jonathan Calmels wrote:
> 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.
> 

Oopps sorry the fcaps bit is crossing over a side discussion.

>>> 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.
> 
examples would help, especially for people not too familiar with this.


> 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.
> 
yeah

> 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.
> 

hrmmm, maybe, I will be happy if they just don't end up complicating
each other

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

yes it is, and yet it still worries me a great deal. I have some of
the same worries as Casey, and also worry that people will take this
as a solution for all use cases, without understanding the issues.

On the other hand walking back the current state of unprivileged use of
user namespaces is a huge issue. Having another approach also pushing
will actually be helpful in some ways.

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

yep

> designed to thwart threat actors. However, it gives userspace the option
> to do so.

again, I don't believe the capabilities system is actually capable of
doing this, it covers some of the use cases. To be fair the LSM doesn't
cover everything either, there are current use cases that just aren't safe,
you either break them or allow them and accept the risks. It relies on
people understanding threat models, and sadly I have become grown quite
grumpy about that topic.

Anyways I will try to finish up my review of the code this weekend.

Powered by blists - more mailing lists