PERFORCE change 85343 for review

[soc-chenk]

http://perforce.freebsd.org/chv.cgi?CH=85343

Change 85343 by soc-chenk at 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.