Subject: Re: Integrating securelevel and kauth(9)
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 03/24/2006 14:44:52
Content-Type: text/plain; charset=us-ascii
On Fri, Mar 24, 2006 at 07:56:27PM +0200, Elad Efrat wrote:
> Outlined in this mail is my proposal for integrating the traditional BSD
> securelevel with the kauth(9) interface.
Thank you. This is a good document to spur discussion.
> By changing the meaning of securelevel, a third-party LKM no longer
> has anything to refer to as a "system security level". I offer two
> possible solutions:
> (a) The securelevel variable will be maintained as "third-party LKM
> securelevel", maintained only for backwards binary
> compatibility. It will have no meaning in the NetBSD kernel,
> but will retain the raise-only property of the current
> (b) Third-party LKMs will be encouraged to remove references to
> securelevel and use the kauth(9) interface, possibly with the
> operation they want guarded from the list of common operations
> for the system scope.
> We can always add more operations to the system scope if they
> are needed, however authors of third-party LKMs that heavily
> depend on securelevel's multiple levels will be advised to make
> use of the new kauth(9) interface's ability to introduce new
> scopes to the system.
My understanding is that kauth will go into the kernel after 4.0 branches.=
Probably just after.
Given that, I actually think it'd be fine to just go with option (b). The=
problem I see with (a) is that it's easy to map a securelevel set request=
(sysctl -w kern.securelevel=3Dfoo) to a bitmap, it's not so easy to do the=
opposite. Since we don't know exactly what aspect of securelevel the LKM=20
is interested in, it's hard to say what securelevel a given LKM should=20
So my suggestion is to make LKMs change. Include a quick description of=20
how to change them (the define you gave was good) and a mapping of what=20
you can find now (if you were interested in making sure ioctl's could=20
happen, you make this call. If you are interested in the ability to access=
devices when others are busy, you make that call).
If this goes into 4.0, then I think you're right and we need both.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----