[PATCH 0/3] Introduce user namespace capabilities

[John Johansen]

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.

> 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

> 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

> If the motivation should be obvious, then it is beyond me, and thus
> would be nice if that obvious thing was stated that everyone else gets.
> 
sure. The cover letter will get updated with this. Seeing as I have been
dealing with this a lot lately. It comes down to user namespaces allow
unprivileged code to access kernel surface area that is usually protected
behind capabilities. This has been leveraged as part of the exploit chain
in the majority of kernel exploits we are seeing.

> E.g. I like to sometimes just test quite alien patch sets for the sake
> of learning and fun (or not so fun, depends) but this patch set does not
> deliver enough information to do anything at all.
> 
under stood, I am playing devils advocate here. Its not that I don't see
value in the proposal, but that I am not sure I see enough value with
the current situation, where so much code has been written around the
assumption that unprivileged user namespaces are safe. Trying to fix
the situation without breaking everything is complicated.

> Hope this clears a bit where I stand. IMHO a good patch set should bring
> the details to the specialists on the topic but also have some wider
> audience motivational stuff in order to make clear where it fits in this
> world :-)
> 
> BR, Jarkko
>