Re: Please read if you use x86 -current

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> But I see no reason why granting access to (say) sd0* has to also
>> grant access to wd* or sd1*, or why granting access to sd0e has to
>> also grant access to sd0[^e].
> The security model is intended to protect (some components of) the
> system from persistent compromise even by a misbehaving process *with
> euid 0*.

Okay, but I don't see how that's relevant.  At most, it imposes a few
more limits on the techniques you can use to grant the relevant access
to the usermode filesystem handler.

> A simple fix would be to add a list of partitions -- or even entire
> disks -- that _may_ be later opened, which could only be altered at
> securelevel 0.

For filesystem implementations, I still think the right way is to not
make userland open the disk at all - rather, have the kernel pass an
already-opened fd when invoking the handler.  The kernel certainly can,
if it feels like it, construct an fd open onto something userland would
not normally be able to open.  (This admittedly handwaves the question
of filesystems that use other than exactly one disk device.  Perhaps
the fds should be passed in from the mount_xxx program?)

Especially since there is then no reason at all to require the
filesystem handler run as root, thereby substantially limiting the
damage it can do even to non-kernel things.

> The more comprehensive fix would probably be code like what Elad
> offered, to actually detect which partitions overlap one another and
> forbid such access.

This strikes me as a good time to quote "Unix does not prevent you from
doing stupid things, because that would also prevent you from doing
clever things".  I semi-regularly find overlapping partitions useful.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B