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>
Sat, 21 Jul 2018 11:17:49 +0000 (12:17 +0100)
commitb3abb451184019c74e6659029b579a93b294e5c8
tree3af6d771a527bbd701a7f6d7058944c3c95d35d8
parentd50017e850d6123d3dc93c1b3eafef6f7bba09f2
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