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.
