Date: Sat, 15 Oct 2005 15:47:08 GMT From: soc-chenk <soc-chenk@FreeBSD.org> To: Perforce Change Reviews <perforce@freebsd.org> Subject: PERFORCE change 85343 for review Message-ID: <200510151547.j9FFl8Nm063688@repoman.freebsd.org>
next in thread | raw e-mail | index | archive | help
http://perforce.freebsd.org/chv.cgi?CH=85343 Change 85343 by soc-chenk@soc-chenk_leavemealone on 2005/10/15 15:46:28 Add remark about problems with BSD style non-privileged mounts to IMPLEMENTATION_NOTES Submitted by: soc-chenk Affected files ... .. //depot/projects/soc2005/fuse4bsd2/IMPLEMENTATION_NOTES#9 edit Differences ... ==== //depot/projects/soc2005/fuse4bsd2/IMPLEMENTATION_NOTES#9 (text+ko) ==== @@ -230,6 +230,37 @@ permissions of fuse devives directly, by chmod, or generally, via devfs(8) rules. +Let's elaborate a bit more on this "naturally useable" BSD mount access +control. This also makes Fuse more exposed to attacks under FreeBSD than +it is under Linux: in Linux, non privileged mountability of Fuse based +filesystems don't open up further privileged tasks. In FreeBSD, mounting +and unmounting will be available more generally if the respective +permissive move ("sysctl vfs.usermount=1") has been done. (With the +help of sudo, one can setup an access control scheme which is similar to +that of Linux, yet we are to give full support for the system provided +facilities.) + +As we said, device permissions can fall into the role of mount +permissions, thus there are limits to the freedom provided by +"vfs.usermount=1", but this happens only with device based filesystems. +The null filesystem (the equivalent of the "bind mounting" facility in +Linux) is one example for a deviceless filesystem. A user can create a +deadlock by null mounting a directory of a Fuse filesystem over another +directory, if the Fuse filesystem requires this other directory during +its operation. And users can freely unmount their filesystems, including +forced unmounts, which can easily lead to panics. (Note that while Linux +tends to stay on the safe side and refuse forced umounts too, if the +filesystem is busy, FreeBSD tends to go forward and perform the forced +unmount and occasionally panic.) So in FreeBSD, we will have to cope +with these, too, if we want to claim that mounting of untrusted daemons +is safe. + +Careful code review slowly leads us toward a state in which this claim +can be maintained. To add, Linux Fuse doesn't seem to rely on its more +protected situation: Linux Fuse was immune to those crashing schemes +that were used to be possible to summon by non-privileged users in +FreeBSD (in Linux, these were attempted as root, of course). + * 1c -- dealing with the "allow other" misery This is related to security, too, but deserves an dedicated subchapter.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510151547.j9FFl8Nm063688>