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.
