Re: Please read if you use x86 -current

[Thor Lancelot Simon <tls%rek.tjls.com@localhost>]

On Thu, Nov 13, 2008 at 03:44:30PM +0200, Antti Kantee wrote:
> 
> Maybe I misunderstand something.  If I do "chmod 666 /dev/${usbdevice}*",
> can you give an example of how that enables access for the root device?

The issue is allowing *any* userspace code to access *any* raw disks at
all.  The way the original 4.4 security policy was designed, it assumed
that either:

        * This would never occur at securelevel > 0
        or
        * disksubr would prohibit access to "in use" partitions.

Unfortunately, basically everyone who wrote disksubr got this wrong
(because they forgot that partitions can overlap and that you can just
change the disklabel if it too is not write protected) and newfangled
creations like stackable disk drivers and wedges actually make this
problem worse.

The problem is not with the device the user space filesystem code is
*supposed* to be accessing.  The problem is that the generic kernel
functionality required to permit it (access to raw disk devices from
userspace) is implemented wrong such that turning it on at all allows
persistent compromise of the system from userspace.  So you may want
that functionality so you can open /dev/sd0b, but unfortunately it 
cannot be turned on piecemeal; a misbehaving process can cross the
user/kernel boundary (in a future run of the system) by stomping on
/dev/wd0d.

In other words: of course you didn't break this.  It's just that because
it's broken, much of the potential security benefit of the clever and
useful thing you did disappears.  Sigh.

-- 
Thor Lancelot Simon                                        
tls%rek.tjls.com@localhost
    "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