fusermount: whitelist known-good filesystems for mountpoints
authorJann Horn <jannh@google.com>
Sat, 14 Jul 2018 11:37:41 +0000 (13:37 +0200)
committerNikolaus Rath <Nikolaus@rath.org>
Wed, 18 Jul 2018 19:32:28 +0000 (20:32 +0100)
commit795ad5d77434f3502e63a70c8a3fda94fa347e3d
tree843dc9a9d0fcfe78acdb71825cf0b4d47553fa0a
parent5018a0c016495155ee598b7e0167b43d5d902414
fusermount: whitelist known-good filesystems for mountpoints

Before:

$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
mount("/dev/fuse", ".", "fuse", MS_NOSUID|MS_NODEV, "fd=3,rootmode=40000,user_id=379777,group_id=5001") = 0
sending file descriptor: Socket operation on non-socket
+++ exited with 1 +++

After:

$ _FUSE_COMMFD=1 priv_strace -s8000 -e trace=mount util/fusermount3 /proc/self/fd
util/fusermount3: mounting over filesystem type 0x009fa0 is forbidden
+++ exited with 1 +++

This patch could potentially have security
impact on some systems that are configured with allow_other;
see https://launchpad.net/bugs/1530566 for an example of how a similar
issue in the ecryptfs mount helper was exploitable. However, the FUSE
mount helper performs slightly different security checks, so that exact
attack doesn't work with fusermount; I don't know of any specific attack
you could perform using this, apart from faking the SELinux context of your
process when someone's looking at a process listing. Potential targets for
overwrite are (looking on a system with a 4.9 kernel):

writable only for the current process:
/proc/self/{fd,map_files}
(Yes, "ls -l" claims that you don't have write access, but that's not true;
"find -writable" will show you what access you really have.)

writable also for other owned processes:
/proc/$pid/{sched,autogroup,comm,mem,clear_refs,attr/*,oom_adj,
oom_score_adj,loginuid,coredump_filter,uid_map,gid_map,projid_map,
setgroups,timerslack_ns}
util/fusermount.c