Martin Husemann wrote:
> On Sat, Dec 30, 2006 at 01:17:21AM +0200, Elad Efrat wrote:
>> [..] the reason? see above: we *can't*
>> reliably distinguish between the two, and sometimes that is is not even
>> something we can do anything about.
> 
> Could you please explain this a bit more detailed? It's nice that you and
> Thor talked about it and know the reason, but I'm both curious and lazy ;-)

let's assume that netbsd has audited all of the drivers it provides, all
of the md code, and that technically, on a vanilla netbsd machine, the
boundaries of each partitions are really kept.

because the above is correct, we don't have the need for a mechanism
like what I proposed, and there is no way to hook in spec_open() to know
whether /dev/wd0a is the same as /dev/rwd0b. instead, each driver does
the boundary check.

now add some 3rd-party drivers to the equation. how well does the above
scale now?

basically, we are *forced* to trust the 3rd-party code to be designed
properly to enforce a policy we claim to provide. technically, of
course, we are lying to our users, and provide them with a false sense
of security: they run netbsd, set the securelevel, think they're safe,
you know the drill.

while this problem will remain correct at all times (we can't really
cover up on all 3rd-party driver flaws), sysdisk(9) let's you do
something about it: it gives you a chance to maintain the raw disk
access policy regardless of the driver code. it shifts the security
policy enforcement back to netbsd.

-e.