From: Bill Studenmund (wrstudennetbsd.org)
Date: Fri Mar 24 2006 - 16:44:52 CST

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On Fri, Mar 24, 2006 at 07:56:27PM +0200, Elad Efrat wrote:
> Hello,
>
> 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
> securelevel.
>
> (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=foo) to a bitmap, it's not so easy to do the
opposite. Since we don't know exactly what aspect of securelevel the LKM
is interested in, it's hard to say what securelevel a given LKM should
see.

So my suggestion is to make LKMs change. Include a quick description of
how to change them (the define you gave was good) and a mapping of what
you can find now (if you were interested in making sure ioctl's could
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.

Take care,

Bill

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

iD8DBQFEJHZjWz+3JHUci9cRApXnAKCWkfO3uwfMBXmWWRJ5514NnGOMKACeNXbo
Vneqd2a5wwZJ3gdLluwX6Fo=
=Ebou
-----END PGP SIGNATURE-----

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]