Date: Fri, 17 May 2024 20:50:44 -0700
From: Jonathan Calmels <jcalmels@...0.net>
To: John Johansen <john.johansen@...onical.com>
Cc: 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>, Jarkko Sakkinen <jarkko@...nel.org>, 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 1/3] capabilities: user namespace capabilities

On Fri, May 17, 2024 at 04:59:41AM GMT, John Johansen wrote:
> On 5/17/24 03:51, Jonathan Calmels wrote:
> > This new capability set would be a universal thing that could be
> > leveraged today without modification to userspace. Moreover, it’s a
> > simple framework that can be extended.
> 
> I would argue that is a problem. Userspace has to change for this to be
> secure. Is it an improvement over the current state yes.

Well, yes and no. With those patches, I can lock down things today on my
system and I don't need to change anything.

For example I can decide that none of my rootless containers started
under SSH will get CAP_NET_ADMIN:

# echo "auth optional pam_cap.so" >> /etc/pam.d/sshd
# echo "!cap_net_admin $USER"     >> /etc/security/capability.conf
# capsh --secbits=$((1 << 8)) -- -c /usr/sbin/sshd

$ ssh localhost 'unshare -r capsh --current'
Current: =ep cap_net_admin-ep
Current IAB: !cap_net_admin

Or I can decide than I don't ever want CAP_SYS_RAWIO in my namespaces:

# sysctl -w cap_bound_userns_mask=0x1fffffdffff

This doesn't require changes to userspace.
Now, granted if you want to have finer-grained controls, it will require
*some* changes in *some* places (e.g. adding new systemd property like
UserNSSet=).

> > Well that’s the thing, from past conversations, there is a lot of
> > disagreement about restricting namespaces. By restricting the
> > capabilities granted by namespaces instead, we’re actually treating the
> > root cause of most concerns.
> > 
> no disagreement there. This is actually Ubuntu's posture with user namespaces
> atm. Where the user namespace is allowed but the capabilities within it
> are denied.
> 
> It does however when not handled correctly result in some very odd failures
> and would be easier to debug if the use of user namespaces were just
> cleanly denied.

Yes but as we established it depends on the use case, both are not
mutually exclusive.

> its not so much the capabilities set as the inheritable part that is
> problematic. Yes I am well aware of where that is required but I question
> that capabilities provides the needed controls here.

Again, I'm not opposed to doing this with LSMs. I just think both could
work well together. We already do that with standard capabilities vs
LSMs, both have their strength and weaknesses.

It's always a tradeoff, do you want a setting that's universal and
coarse, or do you want one that's tailored to specific things but less
ubiquitous.

It's also a tradeoff on usability. If this doesn't get used in practice,
then there is no point.
I would argue that even though capabilities are complicated, they are
more widely understood than LSMs. Are capabilities insufficient in
certain scenarios, absolutely, and that's usually where LSMs come in.

> > This is possible with the security bit introduced in the second patch.
> > The idea of having those separate is that a service which has dropped
> > its capabilities can still create a fully privileged user namespace.
> 
> yes, which is the problem. Not that we don't do that with say setuid
> applications, but the difference is that they were known to be doing
> something dangerous and took measures around that.
> 
> We are starting from a different posture here. Where applications have
> assumed that user namespaces where safe and no measures were needed.
> Tools like unshare and bwrap if set to allow user namespaces in their
> fcaps will allow exploits a trivial by-pass.

Agreed, but we can't really walk back this decision unfortunately.
At least with this patch series system administrators have the ability
to limit such tools.

> What I was trying to get at is two points.
> 1. The written description wasn't clear enough, leaving room for
>    ambiguity.
> 2. That I quest that the behavior should be allowed given the
>    current set of tools that use user namespaces. It reduces exploit
>    codes ability to directly use unprivileged user namespaces but
>    makes it all to easy to by-pass the restriction because of the
>    behavior of the current tool set. ie. user space has to change.

> But again, I believe the fcaps behavior is wrong, because of the state of
> current software. If this had been a proposal where there was no existing
> software infrastructure I would be starting from a different stance.

As mentioned above, userspace doesn't necessarily have to change. I'm
also not sure what you mean by easy to by-pass? If I mask off some
capabilities system wide or in a given process tree, I know for a fact
that no namespace will ever get those capabilities.

Powered by blists - more mailing lists