Date: Sat, 18 May 2024 05:27:27 -0700
From: John Johansen <john.johansen@...onical.com>
To: Jonathan Calmels <jcalmels@...0.net>
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 5/17/24 20:50, Jonathan Calmels wrote:
> 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.
> 
sure, same as with the big no user ns toggle. This is finer and allows
selectively enabling on a per application basis.

> 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=).
> 

yep

>>> 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.
> 
yep

>> 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.
> 
yes, don't get me wrong I am not necessarily advocating an LSM solution
as being necessary. I just want to make sure the trade-offs of the
capabilities solution get discussed to help evaluate whether extending
the current capability model is worth it.

> 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.
> 
yep

> It's also a tradeoff on usability. If this doesn't get used in practice,
> then there is no point.
agreed

> 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.
> 
hrmmm, I am not sure I would agree with capabilities are better understood
than LSMs, At the base level of capability(X) to get permission yes, but
the whole permitting, bounding, ... Really I think most people are just
confused by both

>>> 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.

And that is partly the crux of the issue, if we can't walk back the
decision then the solution becomes more complex

> At least with this patch series system administrators have the ability
> to limit such tools.
> 
agreed

>> 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.

so by-pass will very much depend on the system but from a distro pov
we pretty much have to have bwrap enabled if users want to use flatpaks
(and they do), same story for several other tools. Since this basically
means said tools need to be available by default, most systems the
distro is installed on are vulnerable by default. The trivial by-pass
then becomes the exploit running its payload through one of these tools,
and yes I have tested it.

Could a distro disable these tools by default, and require the user/admin
to enable them, yes though there would be a lot of friction, push back,
and in the end most systems would still end up with them enabled.

With the capibilities approach can a user/admin make their system
more secure than the current situation, absolutely.

Note, that regardless of what happens with patch 1, and 2. I think we
either need the big sysctl toggle, or a version of your patch 3

Powered by blists - more mailing lists