Re: Please read if you use x86 -current

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

On Thu Nov 13 2008 at 08:23:26 -0500, Thor Lancelot Simon wrote:
> On Thu, Nov 13, 2008 at 03:05:17PM +0200, Antti Kantee wrote:
> > On Thu Nov 13 2008 at 07:56:43 -0500, Thor Lancelot Simon wrote:
> > > 
> > > Unfortunately, this requires giving user code access to raw disks, which
> > > poses essentially the same set of security risks in the long term.
> > 
> > How exactly did you arrive at that conclusion?
> 
> If user code can overwrite your root filesystem by accessing the wrong
> disk sectors, you're toast: if not in this instance of the running system,
> then in the next one.
> 
> If you let user code access raw disk devices (so it can manage filesystems
> on USB sticks, for example) the above unfortunately also becomes possible.

First of all, the USB stick will not attach as the same device as a
root partition.  If your root partition is on /dev/sd0*, giving access
to /dev/sd1* will not enable someone to overwrite your root partition.

Second, I am more concerned about outside evil, not so much the user
trying to exploit his own machine.  Of course multiuser machines are
another thing, but as I already said in the previous paragraph, I do
not agree with your concern there either.

The only exception is if the root partition is on the same device as the
untrusted partition.  But I really really don't see how that could happen
without the whole root partition being untrusted and your argument once
again being null and void.

> > > With something like Elad's (abandoned?) code that enforced exclusive use
> > > of potentially overlapping disks/partitions we'd be better off.
> > 
> > How does disk partitioning protect against vulnerabilities in file
> > system code?
> 
> Elad's code forbade any access to any partition that potentially overlapped
> any open partition, or any redefinition of the partition boundaries on any
> disk with any open partition.  If we had it, then user-level filesystems
> would provide the security benefit you're suggesting they do, because
> they'd have no way to access sectors they should not be accessing.
> 
> In other words, of course it is better to run filesystem code for
> removable volumes in userspace than in the kernel.  The problem is that
> the kernel currently doesn't enforce the appropriate security restrictions
> on disk access to actually let us do that without opening up another
> security hole just as bad.

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?