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.
> > 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.
--
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