A privilege escalation flaw in udev

Posted Apr 22, 2009 22:40 UTC (Wed) by nix (subscriber, #2304)
Parent article: A privilege escalation flaw in udev

Can anyone think of a reason why mknod() allows *anyone* to create device
nodes outside /dev? (Or, more generally, why isn't a special mount option
required to create device nodes on a filesystem? The ability to create
device nodes absolutely anywhere is a 'feature' of Unix that I've never
seen be of actual use to anyone except attackers.)

This would have fixed the NFS problem, at least, although not the udev
hole (as udev would have created the node in /dev, which would have had
that flag...)

(More evilly still, if you indicate this in the superblock and have it be
set at mkfs time --- also not problematic for your average system with a
tmpfs /dev --- this lets us recycle the now-unused st_rdev field in the
inode for something else. Not a huge saving, true, but it *is* a saving,
and there are a *lot* of inodes on your average system.)

A privilege escalation flaw in udev

Posted Apr 23, 2009 0:05 UTC (Thu) by jreiser (subscriber, #11027) [Link]

Can anyone think of a reason why mknod() allows *anyone* to create device nodes outside /dev?

Before there was kernel-level virtualization (vmware, xen, kvm, ...) there were partial virtualization environments which needed devices. If you have a machine with trusted users only and/or global protection, then mknod() can be handy for experiments.

A privilege escalation flaw in udev

Posted Apr 23, 2009 0:39 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

there is a mount option to deny the ability to use device nodes on a filesystem, but it's seldom used nowdays (the benifit from splitting up the filesystem into many slices is outweighed by the inconvienience of dealing with the many slices)

A privilege escalation flaw in udev

Posted Apr 23, 2009 15:24 UTC (Thu) by Tet (guest, #5433) [Link] (1 responses)

I'd say LVM fixed that inconvenience long ago, and the benefits of multiple filesystems are still there. I can't really understand why anyone would go with a single large root filesystem.

A privilege escalation flaw in udev

Posted Apr 24, 2009 10:37 UTC (Fri) by nix (subscriber, #2304) [Link]

It can be tricky to get LVM aligned properly for LVM-atop-RAID, and if you
get it wrong you get a silent substantial slowdown...

(RAID-atop-LVM is not prone to this because you don't get the same excess
RMW cycles.)

A privilege escalation flaw in udev

Posted Apr 23, 2009 11:52 UTC (Thu) by etienne_lorrain@yahoo.fr (guest, #38022) [Link] (1 responses)

> Can anyone think of a reason why mknod() allows *anyone*
> to create device nodes outside /dev?

How would you ask ioctl like BLKBSZGET, BLKSSZGET, BLKGETSIZE,
BLKGETSIZE64, HDIO_GETGEO_BIG, to the file system which contains
a file given as parameter?
As an example:
http://www.mirrorservice.org/sites/download.sourceforge.n...

There is maybe a better solution (without having to guess the mount
point *name*) - I am listening...

A privilege escalation flaw in udev

Posted Apr 23, 2009 13:56 UTC (Thu) by nix (subscriber, #2304) [Link]

This looks like a reason why a /sys/block entry containing a device node for each device rather than just a textual representation of (major, minor) might be useful: but that was already rejected :/

A privilege escalation flaw in udev

Posted Apr 23, 2009 13:52 UTC (Thu) by Ross (guest, #4065) [Link]

It's useful for chroot()ed filesystems or to fix /dev problems from another installation by mounting
under /mnt or wherever. The kernel shouldn't "know" that /dev is special.

I believe that installers also create these files in /tmp if you want another example.