--liOOAslEiF7prFVr
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
> >=20
> > Could you please explain this a bit more detailed? It's nice that you a=
nd
> > Thor talked about it and know the reason, but I'm both curious and lazy=
 ;-)
>=20
> 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.
>=20
> 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.
>=20
> 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=
=20
they are loading them into the kernel. There's nothing we can do, short of=
=20
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=
=20
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=
=20
have a lot of rope and there's not much we can/should do about it given=20
our resources.

Now back to the technical discussion. ;-)

With wedges, if we factor it all out of the drivers, this isn't an issue.=
=20
As for the existing drivers, as I recall, it isn't hard to get this right.=
=20
You call a common bounds-checking routine, and you're done. And it's easy=
=20
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=
=20
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
can adjust.

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=
=20
a great basis for deciding if "command bypass" ioctls should be blocked. I=
=20
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.

Take care,

Bill

--liOOAslEiF7prFVr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFFlya2Wz+3JHUci9cRAgVnAJ981JYEKDhffF9d1968o2zC8kynqACfTMaP
Vx9vGKJa12zFoSlSNij0ONc=
=H913
-----END PGP SIGNATURE-----

--liOOAslEiF7prFVr--