From owner-p4-projects@FreeBSD.ORG Sat Oct 15 15:47:10 2005 Return-Path: X-Original-To: p4-projects@freebsd.org Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 8A59F16A421; Sat, 15 Oct 2005 15:47:09 +0000 (GMT) X-Original-To: perforce@freebsd.org Delivered-To: perforce@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E16316A41F for ; Sat, 15 Oct 2005 15:47:09 +0000 (GMT) (envelope-from soc-chenk@freebsd.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B2543D46 for ; Sat, 15 Oct 2005 15:47:08 +0000 (GMT) (envelope-from soc-chenk@freebsd.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j9FFl867063691 for ; Sat, 15 Oct 2005 15:47:08 GMT (envelope-from soc-chenk@freebsd.org) Received: (from perforce@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j9FFl8Nm063688 for perforce@freebsd.org; Sat, 15 Oct 2005 15:47:08 GMT (envelope-from soc-chenk@freebsd.org) Date: Sat, 15 Oct 2005 15:47:08 GMT Message-Id: <200510151547.j9FFl8Nm063688@repoman.freebsd.org> X-Authentication-Warning: repoman.freebsd.org: perforce set sender to soc-chenk@freebsd.org using -f From: soc-chenk To: Perforce Change Reviews Cc: Subject: PERFORCE change 85343 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Oct 2005 15:47:10 -0000 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.