Re: [PATCH 0/3] Introduce user namespace capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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






[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux