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
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
|
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
Thursday, 27 January 2022, 13:55 GMT
Reason for closing: Fixed
Additional comments about closing: shadow-4.11.1-1
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.