5 ms·
> An unprivileged user can use unshare(CLONE_NEWNS|CLONE_NEWUSER) to enter a namespace with the CAP_SYS_ADMIN permission, and then proceed with exploitation to
by stormbrew 5y ago
> An unprivileged user can use unshare(CLONE_NEWNS|CLONE_NEWUSER) to enter a namespace with the CAP_SYS_ADMIN permission, and then proceed with exploitation to root the system.
I'm confused by this, don't you need CAP_SYS_ADMIN to unshare(CLONE_NEWNS) to begin with?
From unshare(2):
> CLONE_NEWNS
> This flag has the same effect as the clone(2) CLONE_NEWNS flag. Unshare the mount namespace, so that the calling process has a private copy of its namespace which is not shared with any other process. Specifying this flag automatically implies CLONE_FS as well. Use of CLONE_NEWNS requires the CAP_SYS_ADMIN capability. For further information, see mount_namespaces(7).
Edit: Oh does this work specifically because you're also unsharing into a new user namespace where you have that capability? This is kind of wild tbh.
- staticassertion 5y agoYeah, a lot of the Linux kernel code was reachable by root, and for a long time the attitude of a lot of kernel maintainers was that privesc from root didn't matter much. But now any code can be root in its own namespace... so all of this code that's far less scrutinized is now reachable.
- boring_twenties 5y agoExactly the main argument that was being made against enabling this by default all those years ago.
- octoberfranklin 5y agoIndeed, this is exactly why containers are not a security feature. Counterintuitively, using containers makes your system less secure because you have to expose this huge kernel attack surface to non-root users.
- deleted 5y ago[deleted]
- alerighi 5y agoSome distributions disable user namespaces by default because they are considered a dangerous feature. And it probably is, in the end.