aboutsummaryrefslogtreecommitdiff
path: root/test
diff options
context:
space:
mode:
authorGravatar Jann Horn <jannh@google.com>2018-07-14 13:37:41 +0200
committerGravatar Nikolaus Rath <Nikolaus@rath.org>2018-07-18 20:32:28 +0100
commit795ad5d77434f3502e63a70c8a3fda94fa347e3d (patch)
tree843dc9a9d0fcfe78acdb71825cf0b4d47553fa0a /test
parent5018a0c016495155ee598b7e0167b43d5d902414 (diff)
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}
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions