OpenBSD Journal

usermount being removed from OpenBSD

Contributed by rueda on from the ain't-no-mountin' dept.

The facility for allowing non-root users to mount file systems has been removed from OpenBSD-current due to security concerns.

Specifically, the value of kern.usermount (as described in the mount(8) and sysctl(3) man pages) will be ignored in OpenBSD 6.0, and the kern.usermount system variable will be absent from later releases.

Theo de Raadt (deraadt@) committed the change:

CVSROOT:	/cvs
Module name:	src
Changes by:	deraadt@cvs.openbsd.org	2016/07/14 09:39:40

Modified files:
	sys/kern       : vfs_syscalls.c kern_sysctl.c 

Log message:
kern.usermount=1 is unsafe for everyone, since it allows any non-pledged
program to call the mount/umount system calls.  There is no way any user
can be expected to keep their system safe / reliable with this feature.
Ignore setting to =1, and after release we'll delete the sysctl entirely.
ok lots of people

Following his own message regarding the recently released set of patches (see earlier article), Ted Unangst (tedu@) posted to announce@:

In addition to the patched bugs, several panics were discovered by NCC that
can be triggered by root or users with the usermount option set. These bugs
are not getting patched because we believe they are only the tip of the
iceberg. The mount system call exposes too much code to userland to be
considered secure.

As remediation, it's recommended to disable usermount. For the forthcoming 6.0
release, the usermount option will be removed.

(Comments are closed)


  1. By Anonymous Coward () on

    I didn't even know that existed. I have always used sudo/doas to mount the volumes.

    If you really need users to be able to mount random things to random file systems, just edit /etc/doas.conf:

    permit nopass :usermount cmd /sbin/mount

    Then add a "usermount" group to /etc/group (or use groupadd(8) instead) and add all users you wish to allow mounting to the group.

    Unlike kern.usermount this is more flexible.

    1. By Edward Ahlsen-Girard (Ed) on

      > I didn't even know that existed. I have always used sudo/doas to mount the volumes.
      >
      > If you really need users to be able to mount random things to random file systems, just edit /etc/doas.conf:
      >
      > permit nopass :usermount cmd /sbin/mount
      >
      > Then add a "usermount" group to /etc/group (or use groupadd(8) instead) and add all users you wish to allow mounting to the group.
      >
      > Unlike kern.usermount this is more flexible.
      >

      Another improvement to security relating to a problem I would never have suspected, since I leave the kernel settings alone.

      Also another reason I like it here.

      1. By Sebastian Rother () on

        > > I didn't even know that existed. I have always used sudo/doas to mount the volumes.
        > >
        > > If you really need users to be able to mount random things to random file systems, just edit /etc/doas.conf:
        > >
        > > permit nopass :usermount cmd /sbin/mount
        > >
        > > Then add a "usermount" group to /etc/group (or use groupadd(8) instead) and add all users you wish to allow mounting to the group.
        > >
        > > Unlike kern.usermount this is more flexible.
        > >
        >
        > Another improvement to security relating to a problem I would never have suspected, since I leave the kernel settings alone.
        >
        > Also another reason I like it here.

        Too late.. the risk is known for years....
        But finaly it got removed...

        And let them fuzz your USB Stack! (I call for this for serval years.. Theo...)


        Kind regards,
        Sebastian Rother

        1. By Anonymous Coward () on

          > Too late.. the risk is known for years....
          > But finaly it got removed...
          >
          > And let them fuzz your USB Stack! (I call for this for serval years.. Theo...)

          They accept patches y'know.

    2. By Anonymous Coward () on

      > I didn't even know that existed. I have always used sudo/doas to mount the volumes.
      >
      > If you really need users to be able to mount random things to random file systems, just edit /etc/doas.conf:
      >
      > permit nopass :usermount cmd /sbin/mount
      >
      > Then add a "usermount" group to /etc/group (or use groupadd(8) instead) and add all users you wish to allow mounting to the group.
      >
      > Unlike kern.usermount this is more flexible.
      >

      But your solution is unusable in multi-users context: every user in your "usermount" group could gain root access easily using mount -o suid on a ffs partition.

      1. By Anonymous Coward () on

        > every user in your "usermount" group could gain root access easily using
        > mount -o suid on a ffs partition.
        

        But according to the man page, there is no "-o suid" option for mount?!??

        1. By Anonymous Coward () on

          > But according to the man page, there is no "-o suid" option for mount?!??
          

          Oops, I stand corrected. I did not notice this sentence on the man page: "Options can be given with (or without) a ‘no’ prefix to invert their meaning."

          Therefore, since the man page explicitly mentions the "-o nosuid" option, the existence of a "-o suid" option is implied.

    3. By Anonymous Coward () on

      > I didn't even know that existed. I have always used sudo/doas to mount the volumes.
      >
      > If you really need users to be able to mount random things to random file systems, just edit /etc/doas.conf:
      >
      > permit nopass :usermount cmd /sbin/mount
      >
      > Then add a "usermount" group to /etc/group (or use groupadd(8) instead) and add all users you wish to allow mounting to the group.
      >
      > Unlike kern.usermount this is more flexible.
      >

      Dangerous idea.

      100% nono.

      Any non-privileged user can mount anything anywhere, like mount something nice into /bin or /etc or just mount fs with SUID binary set on some shell executable. Also schg flag can get sort of "disabled" by mounting something else on top of its dir.

      Better solution would be to write shell script that actually forces mountpoint and mount options to user who can "doas" root that script.

      1. By Anonymous Coward () on

        > Dangerous idea.
        >
        > 100% nono.
        >
        > Any non-privileged user can mount anything anywhere, like mount something nice into /bin or /etc or just mount fs with SUID binary set on some shell executable. Also schg flag can get sort of "disabled" by mounting something else on top of its dir.
        >
        > Better solution would be to write shell script that actually forces mountpoint and mount options to user who can "doas" root that script.

        What was suggested is probably a little less dangerous than kern.usermount, with roughly the same percentage of nono.

        1. By Anonymous Coward () on

          > > Dangerous idea.
          > >
          > > 100% nono.
          > >
          > > Any non-privileged user can mount anything anywhere, like mount something nice into /bin or /etc or just mount fs with SUID binary set on some shell executable. Also schg flag can get sort of "disabled" by mounting something else on top of its dir.
          > >
          > > Better solution would be to write shell script that actually forces mountpoint and mount options to user who can "doas" root that script.
          >
          > What was suggested is probably a little less dangerous than kern.usermount, with roughly the same percentage of nono.
          >

          Well suggesting some replacement with bad security implications(without stating them) is not good at all.

        2. By Anonymous Coward () on

          >
          > What was suggested is probably a little less dangerous than kern.usermount, with roughly the same percentage of nono.
          >

          I disagree.

          kern.usermount had several restrictions on what a user was able to do. All these checks were inside kernel under KERN_LOCK:
          - device accessible by the user (R/W) (so by default nothing)
          - in directory owned by the user (so by default only under /home or /tmp)
          - nosuid,nodev enforced by kernel
          - noexec inherited from mountpoint
          - no NFS export
          - some others checks...

          A "doas script" has to done all these, without the help of KERN_LOCK.

          Just one example: in the "doas script", the directory is owned by the user ? ok. But at time of mount(2) call, does this directory is still the same (and not a symlink to /etc) ? mount(2) syscall operate on paths, so any check which isn't done very carefully could open to TOCTOU.

          but kern.usermount has several problems (like permitting *any* user to use mount(2) instead of just a limited group of users for example), and removing it is a good direction too.

  2. By Chas () on

    Windows and Linux both allow automatic media (dis)mount. Do they handle this securely?

    My phone offers MTP, which doesn't create a filesystem mount, but seems to be handled in gnome. Is this USB protocol handled reasonably?

    Can such features be offered in a secure manner? Would separate system calls that forced noexec/nodev/nosuid/ro/nounion/noupdate fix this?

    1. By grey (grey) on

      > > > Windows and Linux both allow automatic media (dis)mount. Do they handle this securely?
      > > >
      > > > My phone offers MTP, which doesn't create a filesystem mount, but seems to be handled in gnome. Is this USB protocol handled reasonably?
      > > >
      > > > Can such features be offered in a secure manner? Would separate system calls that forced noexec/nodev/nosuid/ro/nounion/noupdate fix this?
      > >
      > > My experience with some operating systems and filesystems, is that they cannot be safely unmounted cleanly without using their paradigms for unmounting them, which is why many OSes have warned: "USB device improperly removed" and such.
      > >
      > > This is not true of all OSes or filesystems. HP3000s which ran the MPE operating system, were legendary for having rock solid filesystems, which could suffer a power loss to a hard drive,keep running, and from the moment when the hard drive was unexpectedly unmounted to when the hard drive was turned back on, no one noticed any system downtime, though possibly system lag and some data inaccessibility.
      > >
      > > The Commodore Amiga's FFS, which would flush all writes to disk approximately every 1second, was also considered very robust for its era (e.g. 1985-1994). The operating system did not provide a "shutdown" mechanism, the computers had physical hardware power switches, which were used to power off and on the system, much like a television. They worked: flawlessly. Indeed, there are more problems with Amiga enthusiasts in the present era, using SSDs to replace their aged hard drives, where the SSD internals, are so slow that the Amiga powers up, before the SSD has initialized, and the boot ROM/kickstart hangs because it is still waiting on the SSD. Ironically: old physical hard drives, don't exhibit such effects.
      > >
      > > By comparison, systems like the 68000 based AT&T Unix PC, actually tied their power switch, to logic on their mainboards, so when an individual would press the "power off" button, it would actually trigger an event which would begin to run a series of shutdown scripts within the OS to sync and cleanly unmount the filesystems, before cutting power. They take a bit longer to power off than a standard hardware switch, and presumably should only be operated when plugged into a UPS for safe operation in the event of power outages, which could cause the filesystem to require a fsck upon next bring up in the event of a power failure.
      >
      >

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]