On Fri, Mar 24, 2006 at 07:56:27PM +0200, Elad Efrat wrote:
quoted text
> Hello,
>=20
> 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.

quoted text
>      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:
>=20
>      (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
>          securelevel.
>=20
>      (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.
>=20
>          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.=
=20
Probably just after.

Given that, I actually think it'd be fine to just go with option (b). The=
=20
problem I see with (a) is that it's easy to map a securelevel set request=
=20
(sysctl -w kern.securelevel=3Dfoo) to a bitmap, it's not so easy to do the=
=20
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
see.

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=
=20
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.

Take care,

Bill