Subject: Re: new kpi proposal, sysdisk(9)
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <email@example.com>
Date: 12/30/2006 18:55:50
Content-Type: text/plain; charset=us-ascii
On Sat, Dec 30, 2006 at 06:19:06PM +0200, Elad Efrat wrote:
> 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 a=
> > 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?
Well, part of the idea is that each device calls common code to check=20
partition boundaries. Only the drive itself (its softc) has the info=20
needed for checking, so we have to get into some drive-aware code to=20
initiate the check.
> 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.
Kinda. We are only lying to our users (as opposed to our users lying to
themselves) if we make statements about said 3rd-party drivers. I've been
editing and editing this response, and I keep coming back to this. So I'll
try to clearly say what I think.
We're talking about drivers in the kernel. Our users HAVE to trust them as=
they are loading them into the kernel. There's nothing we can do, short of=
a less-trusted run environment (said driver running at something between=20
kernel and user priviledge). That's a fundamental thing, and I think that=
we need to not budge on it. i.e. I think it's a policial bad step to=20
develop technical solutions to make us comfortable about making promises=20
here. We should make no promises.
Giving our users ways to trust a driver only so far is ok. But I think=20
it's important we stay out of the promise zone here; our users will still=
have a lot of rope and there's not much we can/should do about it given=20
Now back to the technical discussion. ;-)
With wedges, if we factor it all out of the drivers, this isn't an issue.=
As for the existing drivers, as I recall, it isn't hard to get this right.=
You call a common bounds-checking routine, and you're done. And it's easy=
to notice if the driver is making this call, thus auditing is easy.
> 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.
As above, I do like the idea of shifting functionality into NetBSD-common=
code. To be honest, I don't think the partition bounds checking on raw=20
access is a good justification for the change you want to make. However=20
part of our new auth methodology is that we give admins knobs that they=20
One other use for this, though, comes to my mind. It involves the=20
raw-access ioctl discussions we had. Unfortunately I do not remember the=20
outcome of this discussion, but what you're describing above strikes me as=
a great basis for deciding if "command bypass" ioctls should be blocked. I=
personally am much more likely to trust a driver to get the partition=20
bounds checking code right as opposed to getting every nuance of=20
pass-through ioctls right.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)
-----END PGP SIGNATURE-----