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)
By Anonymous Coward (163.172.211.135) on
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.
Comments
By Edward Ahlsen-Girard (Ed) on
>
> 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.
Comments
By Sebastian Rother (109.192.79.135) on
> >
> > 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
Comments
By Anonymous Coward (92.41.49.165) on
> 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.
By Anonymous Coward (176.10.107.180) on
>
> 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.
Comments
By Anonymous Coward (72.95.157.192) on
But according to the man page, there is no "-o suid" option for mount?!??
Comments
By Anonymous Coward (72.95.157.192) on
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.
By Anonymous Coward (46.243.142.135) on
>
> 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.
Comments
By Anonymous Coward (85.248.227.165) on
>
> 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.
Comments
By Anonymous Coward (104.250.169.130) on
> >
> > 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.
By Anonymous Coward (176.10.104.243) 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.
By Chas (147.154.235.102) on
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?
Comments
By grey (grey) on
> > >
> > > 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.
>
>