FS#70768 - [shadow] retain CAP_SETFCAP with new*idmap

Attached to Project: Arch Linux
Opened by Morten Linderud (Foxboron) - Sunday, 09 May 2021, 22:12 GMT
Last edited by Allan McRae (Allan) - Thursday, 27 January 2022, 13:55 GMT
Task Type Bug Report
Category Security
Status Closed
Assigned To Levente Polyak (anthraxx)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

I believe this is partially a security issue, but I'm not 100% sure if I understand it :)

In some circumstances there is a chance that when you map uid 0 into a child namespace one could set capabilities on valid to the parent namespace. The shadow package needs to take this into account the figuring out new sub*id mappings for child namespaces.

Backport https://github.com/shadow-maint/shadow/pull/334

Following this discussion: https://discuss.linuxcontainers.org/t/containers-do-not-launch-on-linux-5-12/10995
This task depends upon

Closed by  Allan McRae (Allan)
Thursday, 27 January 2022, 13:55 GMT
Reason for closing:  Fixed
Additional comments about closing:  shadow-4.11.1-1
Comment by Christian Brauner (brauner) - Monday, 10 May 2021, 08:18 GMT
Sorry, I was unclear in the issue that triggered this request.
User namespaces allow you to map uid to uid 0, i.e. you can create containers that use a separate user namespace where the container uses the same id mapping as the host. In this case the container can do setcap cap_net_raw+ep ./file and the capability is valid in the user namespace of the container but also in the ancestor user namespace.
This has been fixed in the kernel by verifying that the creator of the new user namespace has CAP_SETFCAP in its own user namespace. If they do then they are allowed to map uid 0 into the new user namespace otherwise they aren't.

The newuidmap binary currently drops all capabilities apart from CAP_SETUID when it writes the uid mapping and Archlinux ships newuidmap with CAP_SETUID set and not as a setuid binary. This means if real root calls newuidmap to map uid 0 into a new user namespace newuidmap would fail to do so because it drops CAP_SETFCAP even though real root very much should be able to map uid 0 into the new user namespace. To handle this case the patch I linked retains CAP_SETFCAP if uid 0 is supposed to be mapped into the new user namespace. If the caller has CAP_SETFCAP mapping uid 0 into the new user namespace will then work correctly. This doesn't change anything, i.e. this used to work before and the newuidmap binary doesn't need to change that. It just fixes the newuidmap binary to handle this fix.
Comment by Morten Linderud (Foxboron) - Monday, 10 May 2021, 08:26 GMT
Ahh! Thanks for the detailed explanation :)
Comment by Michel Koss (MichelKoss1) - Monday, 10 May 2021, 18:23 GMT
Do I understand this correctly that the newuidmap binary doesn't need SETFCAP but only aforementioned upstream patch?
Comment by Giancarlo Razzolini (grazzolini) - Monday, 10 May 2021, 18:58 GMT
That is my understanding too, yes. I plan to push an updated shadow package today/early tomorrow.
Comment by Christian Brauner (brauner) - Tuesday, 11 May 2021, 07:16 GMT
The binary for now only needs the upstream patch and no additional capabilities. It is very unlikely for someone other than root to map uid 0 into a user namespace. If people start mapping uid 0 by placing appropriate lines that would allow this in /etc/subuid or /etc/subgid then we can enable setcap later. But for now I would just try and see whether this is even widely used (which I doubt).

Loading...