NetBSD Problem Report #29360

From andreas.wiese@inf.tu-dresden.de  Sun Feb 13 20:19:41 2005
Return-Path: <andreas.wiese@inf.tu-dresden.de>
Received: from mail.inf.tu-dresden.de (mail.inf.tu-dresden.de [141.76.2.1])
	by narn.netbsd.org (Postfix) with ESMTP id 2229C63B400
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 13 Feb 2005 20:19:40 +0000 (UTC)
Message-Id: <420FB688.7050605@inf.tu-dresden.de>
Date: Sun, 13 Feb 2005 21:20:24 +0100
From: Andreas Wiese <andreas.wiese@inf.tu-dresden.de>
Reply-To:
To: gnats-bugs@netbsd.org
Subject: vfs.generic.usermount and mount(8) general questions

>Number:         29360
>Category:       kern
>Synopsis:       vfs.generic.usermount and mount(8) general questions
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   unknown
>Arrival-Date:   Sun Feb 13 20:20:00 +0000 2005
>Last-Modified:  Mon Sep 07 13:05:02 +0000 2009
>Originator:     Andreas Wiese <andreas.wiese@inf.tu-dresden.de>
>Release:        
>Organization:

>Environment:

>Description:
  >Submitter-Id:	net
  >Originator:	Andreas Wiese
  >Organization:	Technische Universität, Germany
  >Confidential:	no
  >Synopsis:	Why has [node] to be owned by user?
  >Severity:	non-critical
  >Priority:	low
  >Category:	misc
  >Class:		change-request
  >Release:	NetBSD 2.99.15
  >Environment:
 System: NetBSD schroeder.o-zonenloch.home 2.99.15 NetBSD 2.99.15 
 (SCHROEDER) #0: Sat Feb 12 17:39:13 CET 2005 
 root@schroeder.o-zonenloch.home:/sys/arch/i386/compile/SCHROEDER i386
 Architecture: i386
 Machine: i386
  >Description:
 I dunno if this is the 'right' way for asking general questions, but you
 could also call it a change-request.  If that's the wrong way, please let
 me know.

 Why is it necessary for (ordinary-) user-mounts, that the node, where the
 filesystem should be mounted is owned by the user?  Shouldn't it be enough
 when the directory is owned (and eventually writeable) by a group, the user
 belongs to?  The problem I have with the actual behaviour is, that it's
 obviously only possible for _one_ ordinary user to mount a filesystem
 somewhere.  Of course I could stuff all users, who should be able to
 user-mount into one group, give this group read-permissions to the special-
 file and let them all mount the filesystem to some place inside their home
 directories, but I'd prefer to let them mount them somewhere to /mnt or
 similar, so that everybody benefits from it.  But unfortunately I can't
 have one directory with more than one owner, obviously.

 I'd like to have the device files _and_ the mount points owned by
 root:operator, the users, who should be able to mount(8) as members in
 operator, and vfs.generic.usermount=1 to be working.

 Something like this:

 #v+
 awiese@schroeder:~> ls -ld /mnt/cd0a
 drwxrwxr-x  2 root  operator  512 Jan 18  2004 /mnt/cd0a
 awiese@schroeder:~> ls -l /dev/cd0a
 brw-rw----  1 root  operator  6, 0 Jan 11  2004 /dev/cd0a
 awiese@schroeder:~> id -Gn
 users wheel kmem operator games
 awiese@schroeder:~> sysctl vfs.generic.usermount
 vfs.generic.usermount = 1
 awiese@schroeder:~> grep cd0a /etc/fstab
 /dev/cd0a	/mnt/cd0a	cd9660	ro,noauto,hidden	0 0
 awiese@schroeder:~>
 #v-

 But this (of course) doesn't work (yet? ;)

 #v+
 awiese@schroeder:~> mount /dev/cd0a
 mount_cd9660: /dev/cd0a on /mnt/cd0a: Operation not permitted
 awiese@schroeder:~>
 #v-

 Is there any security or other consideration in 'my' behaviour I've
 missed?

 I don't want to be able to give any mount options via -o or similar, it
 would be enough, when the users would be able to mount the filesystem as
 specified in /etc/fstab.

 Another possibility I can imagine is to make /sbin/mount owned by
 root:operator and chmod it to 4750, but that causes less nice feelings
 somewhere near my stomache...

  >How-To-Repeat:
 	n/a
  >Fix:
 	n/a

>How-To-Repeat:

>Fix:

Unknown
>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: gnats-admin->kern-bug-people
Responsible-Changed-By: soren@netbsd.org
Responsible-Changed-When: Wed, 02 Mar 2005 19:47:10 +0000
Responsible-Changed-Why:
kernel bug.


From: Elad Efrat <elad@NetBSD.org>
To: gnats-bugs@netbsd.org, tech-kern@netbsd.org
Cc: 
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 02:01:44 -0400

 Hi,

 I just came across this PR.

 The check that a non-root user owns the mount-point directory was
 introduced way before vfs.generic.usermount. In fact, it seems that it
 actually removed the root check, and allowed non-root users to freely
 mount file-systems:

     http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/vfs_syscalls.c.diff?r1=1.42&r2=1.43&f=h

 In other words, I don't see a direct relation between the two.

 I believe your (the submitter's) suggestion makes a lot of sense: if
 we only care about read access to the device file when mounting as a
 non-root user, why should we care about more than write access (i.e.,
 ownership) for the mount-point in the same scenario?

 What I suggest is that since we already have a check to ensure the
 user is allowed to mount a file-system, we should replace the
 following code in kern/vfs_syscalls.c:

 309: /*
 310:  * If the user is not root, ensure that they own the directory
 311:  * onto which we are attempting to mount.
 312:  */
 313: if ((error = VOP_GETATTR(vp, &va, l->l_cred)) != 0 ||
 314:     (va.va_uid != kauth_cred_geteuid(l->l_cred) &&
 315:     (error = kauth_authorize_generic(l->l_cred,
 316:     KAUTH_GENERIC_ISSUSER, NULL)) != 0)) {
 317:         return error;
 318: }

 With something like the following:

 /* Ensure that the user can write to the mount-point. */
 if ((error = VOP_ACCESS(vp, VWRITE, l->l_cred)) != 0)
     return error;

 Does anyone see any drawbacks to this approach? If not, I'll change
 the relevant code.

 Thanks,

 -e.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Elad Efrat <elad@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, tech-kern@NetBSD.org
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 11:20:09 +0200

 On Sun, Sep 06, 2009 at 02:01:44AM -0400, Elad Efrat wrote:
 > Hi,
 > 
 > I just came across this PR.
 > 
 > The check that a non-root user owns the mount-point directory was
 > introduced way before vfs.generic.usermount. In fact, it seems that it
 > actually removed the root check, and allowed non-root users to freely
 > mount file-systems:
 > 
 >     http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/vfs_syscalls.c.diff?r1=1.42&r2=1.43&f=h

 Yes, vfs.generic.usermount was introduced later, because of security issues
 that usermounts could cause. AFAIK the know security issues with
 usermounts are fixed, but still it's better to have it disabled on systems
 where it's not needed.


 > 
 > In other words, I don't see a direct relation between the two.
 > 
 > I believe your (the submitter's) suggestion makes a lot of sense: if
 > we only care about read access to the device file when mounting as a
 > non-root user, why should we care about more than write access (i.e.,
 > ownership) for the mount-point in the same scenario?
 > 
 > What I suggest is that since we already have a check to ensure the
 > user is allowed to mount a file-system, we should replace the
 > following code in kern/vfs_syscalls.c:
 > 
 > 309: /*
 > 310:  * If the user is not root, ensure that they own the directory
 > 311:  * onto which we are attempting to mount.
 > 312:  */
 > 313: if ((error = VOP_GETATTR(vp, &va, l->l_cred)) != 0 ||
 > 314:     (va.va_uid != kauth_cred_geteuid(l->l_cred) &&
 > 315:     (error = kauth_authorize_generic(l->l_cred,
 > 316:     KAUTH_GENERIC_ISSUSER, NULL)) != 0)) {
 > 317:         return error;
 > 318: }
 > 
 > With something like the following:
 > 
 > /* Ensure that the user can write to the mount-point. */
 > if ((error = VOP_ACCESS(vp, VWRITE, l->l_cred)) != 0)
 >     return error;
 > 
 > Does anyone see any drawbacks to this approach? If not, I'll change
 > the relevant code.

 Yes, that would mean a user could mount his own FS over e.g. /tmp, or
 /var/mail. that's bad.
 I think that checking the user owns the mount point is the right thing to do.
 I think a sysctl to control whenever to check for group ownerchip instead
 of user ownerchip would work, though. It's up to the admin to carefully
 choose a group for devices and mount points :)

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Antti Kantee <pooka@cs.hut.fi>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Elad Efrat <elad@NetBSD.org>, gnats-bugs@NetBSD.org,
	tech-kern@NetBSD.org
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 17:46:41 +0300

 On Sun Sep 06 2009 at 11:20:09 +0200, Manuel Bouyer wrote:
 > On Sun, Sep 06, 2009 at 02:01:44AM -0400, Elad Efrat wrote:
 > > Hi,
 > > 
 > > I just came across this PR.
 > > 
 > > The check that a non-root user owns the mount-point directory was
 > > introduced way before vfs.generic.usermount. In fact, it seems that it
 > > actually removed the root check, and allowed non-root users to freely
 > > mount file-systems:
 > > 
 > >     http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/vfs_syscalls.c.diff?r1=1.42&r2=1.43&f=h
 > 
 > Yes, vfs.generic.usermount was introduced later, because of security issues
 > that usermounts could cause. AFAIK the know security issues with
 > usermounts are fixed, but still it's better to have it disabled on systems
 > where it's not needed.

 Really?  If you are going to claim a fixed security issue, please provide
 some reference to the issue you are talking about.  As I recall, it was
 added because mounting enough file systems (I used kernfs for testing back
 then) would cause the kernel to run out of memory and the system to panic.

 > > With something like the following:
 > > 
 > > /* Ensure that the user can write to the mount-point. */
 > > if ((error = VOP_ACCESS(vp, VWRITE, l->l_cred)) != 0)
 > >     return error;
 > > 
 > > Does anyone see any drawbacks to this approach? If not, I'll change
 > > the relevant code.
 > 
 > Yes, that would mean a user could mount his own FS over e.g. /tmp, or
 > /var/mail. that's bad.
 > I think that checking the user owns the mount point is the right thing to do.

 I agree that ownership is the right check.

 > I think a sysctl to control whenever to check for group ownerchip instead
 > of user ownerchip would work, though. It's up to the admin to carefully
 > choose a group for devices and mount points :)

 I am opposed to adding a kernel switch with confusing security
 implications.  Especially since the issue in the PR is corner-case (IMHO,
 of course) and can be solved easily at user-level with a wrapper without
 affecting everyone.

 (at the very least, you'd need to check owner || (group && write).
 and even then, there are difficult-to-foresee consequences e.g. a
 sticky-bitty group-shared working directory or group +wx "drop site"
 directory)

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Antti Kantee <pooka@cs.hut.fi>, Elad Efrat <elad@NetBSD.org>,
        gnats-bugs@NetBSD.org, tech-kern@NetBSD.org
Cc: 
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 17:24:56 +0200

 On Sun, Sep 06, 2009 at 05:46:41PM +0300, Antti Kantee wrote:
 > > > introduced way before vfs.generic.usermount. In fact, it seems that it
 > > > actually removed the root check, and allowed non-root users to freely
 > > > mount file-systems:
 > > > 
 > > >     http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/vfs_syscalls.c.diff?r1=1.42&r2=1.43&f=h
 > > 
 > > Yes, vfs.generic.usermount was introduced later, because of security issues
 > > that usermounts could cause. AFAIK the know security issues with
 > > usermounts are fixed, but still it's better to have it disabled on systems
 > > where it's not needed.
 > 
 > Really?  If you are going to claim a fixed security issue, please provide
 > some reference to the issue you are talking about.

 NetBSD-SA1999-006.txt.asc
 NetBSD-SA1999-007.txt.asc

 vfs.generic.usermount on Feb 16 2000 (vfs_syscalls.c rev 1.150).

 > As I recall, it was
 > added because mounting enough file systems (I used kernfs for testing back
 > then) would cause the kernel to run out of memory and the system to panic.

 I think the discussion about this also refereced the above SA (which had been
 fixed at this time, but showed how fragile usermounts are), but I may
 be wrong.


 > 
 > > > With something like the following:
 > > > 
 > > > /* Ensure that the user can write to the mount-point. */
 > > > if ((error = VOP_ACCESS(vp, VWRITE, l->l_cred)) != 0)
 > > >     return error;
 > > > 
 > > > Does anyone see any drawbacks to this approach? If not, I'll change
 > > > the relevant code.
 > > 
 > > Yes, that would mean a user could mount his own FS over e.g. /tmp, or
 > > /var/mail. that's bad.
 > > I think that checking the user owns the mount point is the right thing to do.
 > 
 > I agree that ownership is the right check.
 > 
 > > I think a sysctl to control whenever to check for group ownerchip instead
 > > of user ownerchip would work, though. It's up to the admin to carefully
 > > choose a group for devices and mount points :)
 > 
 > I am opposed to adding a kernel switch with confusing security
 > implications.  Especially since the issue in the PR is corner-case (IMHO,
 > of course) and can be solved easily at user-level with a wrapper without
 > affecting everyone.
 > 
 > (at the very least, you'd need to check owner || (group && write).
 > and even then, there are difficult-to-foresee consequences e.g. a
 > sticky-bitty group-shared working directory or group +wx "drop site"
 > directory)

 I didn't say adding group-based usermounts was a good idea. I just said
 that if it was done it should be sysctl'able :)

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Elad Efrat <elad@NetBSD.org>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@netbsd.org, tech-kern@netbsd.org, 
	Antti Kantee <pooka@netbsd.org>
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 13:02:02 -0400

 On Sun, Sep 6, 2009 at 5:20 AM, Manuel Bouyer<bouyer@antioche.eu.org> wrote:

 >> Does anyone see any drawbacks to this approach? If not, I'll change
 >> the relevant code.
 >
 > Yes, that would mean a user could mount his own FS over e.g. /tmp, or
 > /var/mail. that's bad.

 Forgot about those world-writable-but-sticky directories. Righto. :)

 > I think that checking the user owns the mount point is the right thing to do.
 > I think a sysctl to control whenever to check for group ownerchip instead
 > of user ownerchip would work, though. It's up to the admin to carefully
 > choose a group for devices and mount points :)

 I agree with Antti here about the sysctl, but I want to replace the
 root check, eventually. What do you guys think about replacing the
 owner/root check with a kauth action that does the same in a
 bsd44-suser listener?

 Thanks,

 -e.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: Elad Efrat <elad@NetBSD.org>
Cc: gnats-bugs@NetBSD.org, tech-kern@NetBSD.org,
        Antti Kantee <pooka@NetBSD.org>
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 20:11:59 +0200

 On Sun, Sep 06, 2009 at 01:02:02PM -0400, Elad Efrat wrote:
 > On Sun, Sep 6, 2009 at 5:20 AM, Manuel Bouyer<bouyer@antioche.eu.org> wrote:
 > 
 > >> Does anyone see any drawbacks to this approach? If not, I'll change
 > >> the relevant code.
 > >
 > > Yes, that would mean a user could mount his own FS over e.g. /tmp, or
 > > /var/mail. that's bad.
 > 
 > Forgot about those world-writable-but-sticky directories. Righto. :)
 > 
 > > I think that checking the user owns the mount point is the right thing to do.
 > > I think a sysctl to control whenever to check for group ownerchip instead
 > > of user ownerchip would work, though. It's up to the admin to carefully
 > > choose a group for devices and mount points :)
 > 
 > I agree with Antti here about the sysctl, but I want to replace the
 > root check, eventually. What do you guys think about replacing the
 > owner/root check with a kauth action that does the same in a
 > bsd44-suser listener?

 Fine with me

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Antti Kantee <pooka@netbsd.org>
To: Elad Efrat <elad@NetBSD.org>
Cc: Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@netbsd.org,
	tech-kern@netbsd.org
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 21:21:06 +0300

 On Sun Sep 06 2009 at 13:02:02 -0400, Elad Efrat wrote:
 > I agree with Antti here about the sysctl, but I want to replace the
 > root check, eventually. What do you guys think about replacing the
 > owner/root check with a kauth action that does the same in a
 > bsd44-suser listener?

 Well, sounds sensible in general, but just some food-for-thought: I wonder
 how much of an "ufs syndrome" you are creating for security code, i.e. how
 difficult will it be to implement a security model without copypasting
 "bsd44" and modifying a few bits here and there and eventually ending
 up with 20 slightly different copies of whatever the secmodel equivalent
 of rename is?

From: Antti Kantee <pooka@cs.hut.fi>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Elad Efrat <elad@NetBSD.org>, gnats-bugs@NetBSD.org,
	tech-kern@NetBSD.org
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 21:23:19 +0300

 On Sun Sep 06 2009 at 17:24:56 +0200, Manuel Bouyer wrote:
 > > As I recall, it was
 > > added because mounting enough file systems (I used kernfs for testing back
 > > then) would cause the kernel to run out of memory and the system to panic.
 > 
 > I think the discussion about this also refereced the above SA (which had been
 > fixed at this time, but showed how fragile usermounts are), but I may
 > be wrong.

 Apparently you can still make the system panic by just mounting a zillion
 kernfs's (which is just one way to make the kernel run out of memory).
 I think the problem is that somewhere along the line kmem_alloc(KM_SLEEP)
 returns NULL.  I remember there being discussions that the caller of
 kmem_alloc() should always check against NULL return, but that of course
 makes calling it slightly inconvenient.

From: Elad Efrat <elad@NetBSD.org>
To: Antti Kantee <pooka@netbsd.org>, Manuel Bouyer <bouyer@antioche.eu.org>, gnats-bugs@netbsd.org, 
	tech-kern@netbsd.org
Cc: 
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Sun, 6 Sep 2009 14:30:25 -0400

 On Sun, Sep 6, 2009 at 2:21 PM, Antti Kantee<pooka@netbsd.org> wrote:
 > On Sun Sep 06 2009 at 13:02:02 -0400, Elad Efrat wrote:
 >> I agree with Antti here about the sysctl, but I want to replace the
 >> root check, eventually. What do you guys think about replacing the
 >> owner/root check with a kauth action that does the same in a
 >> bsd44-suser listener?
 >
 > Well, sounds sensible in general, but just some food-for-thought: I wonder
 > how much of an "ufs syndrome" you are creating for security code, i.e. how
 > difficult will it be to implement a security model without copypasting
 > "bsd44" and modifying a few bits here and there and eventually ending
 > up with 20 slightly different copies of whatever the secmodel equivalent
 > of rename is?

 Funny that you ask: this is exactly the bit I removed from the reply. :)

 Similar to how securelevel was separated from bsd44, I plan on doing
 the same for suser, including removing any code that doesn't check
 solely for euid 0. In other words, I want the securelevel secmodel to
 only care about the securelevel variable and the suser secmodel to
 only care about euid 0. Bsd44 will remain as a "grouping" entity for
 both of them.

 The remaining checks (tons of uid/gid/whatever comparisons, etc.) will
 be moved to their own respective listeners in each subsystem --
 similar to what Iain had done with the bluetooth code.

 That way, we won't have to duplicate anything because the subsystem
 itself will contribute the "default" access controls. Secmodels will
 be able to implement only what they're designed to.

 Sounds okay?

 Thanks,

 -e.

From: Thor Lancelot Simon <tls@panix.com>
To: Antti Kantee <pooka@cs.hut.fi>, Manuel Bouyer <bouyer@antioche.eu.org>,
	Elad Efrat <elad@NetBSD.org>, gnats-bugs@NetBSD.org,
	tech-kern@NetBSD.org
Cc: 
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general
	questions
Date: Sun, 6 Sep 2009 17:21:26 -0400

 On Sun, Sep 06, 2009 at 09:23:19PM +0300, Antti Kantee wrote:
 > 
 > Apparently you can still make the system panic by just mounting a zillion
 > kernfs's (which is just one way to make the kernel run out of memory).
 > I think the problem is that somewhere along the line kmem_alloc(KM_SLEEP)
 > returns NULL.  I remember there being discussions that the caller of
 > kmem_alloc() should always check against NULL return, but that of course
 > makes calling it slightly inconvenient.

 Supposedly, allocations with KM_SLEEP won't return NULL, so code can
 safely assume they don't.  I've been told at least once that it is bad
 style to check...!

 -- 
 Thor Lancelot Simon	                                   tls@rek.tjls.com
     "Even experienced UNIX users occasionally enter rm *.* at the UNIX
      prompt only to realize too late that they have removed the wrong
      segment of the directory structure." - Microsoft WSS whitepaper

From: Wolfgang Solfrank <Wolfgang@Solfrank.net>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: Elad Efrat <elad@NetBSD.org>, gnats-bugs@NetBSD.org, 
 tech-kern@NetBSD.org
Subject: Re: kern/29360: vfs.generic.usermount and mount(8) general questions
Date: Mon, 07 Sep 2009 13:05:59 +0200

 Hi,

 > Yes, vfs.generic.usermount was introduced later, because of security issues
 > that usermounts could cause. AFAIK the know security issues with
 > usermounts are fixed, but still it's better to have it disabled on systems
 > where it's not needed.

 The main reason for not allowing user mounts by default is that it's
 quite easy to make a system panic by mounting some (more or less) carefully
 crafted media.

 Ciao,
 Wolfgang
 -- 
 Wolfgang@Solfrank.net				Wolfgang Solfrank

>Unformatted:

Home	PR Database Search