Re: [PATCH 0/3] Introduce user namespace capabilities
John Johansen <[email protected]> Tue, 21 May 2024 07:45:20 -0700
| Newsgroups | dev.linux.lists.containers,org.kernel.vger.keyrings,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-security-module |
|---|---|
| Organization | Canonical |
| Message-ID | <[email protected]> |
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 >