Re: Please read if you use x86 -current

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Thu Nov 13 2008 at 09:03:39 -0500, Thor Lancelot Simon wrote:
> 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.

I am not worried if I broke or didn't break anything.  I am worried
about how to fix it.  To fix it, I need to understand what's wrong.
I still don't.  Maybe I need to think about it for a while.  (Maybe the
attack angle is more subtle than your dramatic presentation suggests ;)

The questions I have based on your examples above are:
* how will whatever misbehaving process get access to wd0d if it can't
  open any device node that is an alias for wd0d?
* if it is such a problem, why isn't the world full of exploited systems
  where some process (say, firefox) just randomly decided to stomp wd0d?

In other words, shouldn't the file system permissions protect us from
what the rest of the kernel doesn't?