that can't happen as early as the other init functions as called from
cpu_startup() -- for example, register kauth(9) listeners.
Put unprivileged policy in the x86 code; used by i386, amd64, and xen.
This is important in the case someone manages to load the suser secmodel
and remove subsystem specific listeners; without this change they would
have ended up with a root user that can only do privileged operations.
but access control) user mounting policies: enforced MNT_NOSUID and
MNT_NODEV, no MNT_EXPORT, MNT_EXEC propagation. This can be useful for
secmodels that are interested in simply adding finer grained user mount
support.
- Add a mount subsystem listener for KAUTH_REQ_SYSTEM_MOUNT_GET.
close to it). Useful for secmodels.
Replace open-coded form with it in secmodel code (securelevel, keylock).
Note: I need to find a way to make secmodel_keylock.c ~<100 lines.
Note: the ipf code contains a lot of ifdefs, some of them for NetBSD
versions that are no longer maintained. It won't make the code more
readable, but we should consider removing them.
- Separate the suser part of the bsd44 secmodel into its own secmodel
and directory, pending even more cleanups. For revision history
purposes, the original location of the files was
src/sys/secmodel/bsd44/secmodel_bsd44_suser.c
src/sys/secmodel/bsd44/suser.h
- Add a man-page for secmodel_suser(9) and update the one for
secmodel_bsd44(9).
- Add a "secmodel" module class and use it. Userland program and
documentation updated.
- Manage secmodel count (nsecmodels) through the module framework.
This eliminates the need for secmodel_{,de}register() calls in
secmodel code.
- Prepare for secmodel modularization by adding relevant module bits.
The secmodels don't allow auto unload. The bsd44 secmodel depends
on the suser and securelevel secmodels. The overlay secmodel depends
on the bsd44 secmodel. As the module class is only cosmetic, and to
prevent ambiguity, the bsd44 and overlay secmodels are prefixed with
"secmodel_".
- Adapt the overlay secmodel to recent changes (mainly vnode scope).
- Stop using link-sets for the sysctl node(s) creation.
- Keep sysctl variables under nodes of their relevant secmodels. In
other words, don't create duplicates for the suser/securelevel
secmodels under the bsd44 secmodel, as the latter is merely used
for "grouping".
- For the suser and securelevel secmodels, "advertise presence" in
relevant sysctl nodes (sysctl.security.models.{suser,securelevel}).
- Get rid of the LKM preprocessor stuff.
- As secmodels are now modules, there's no need for an explicit call
to secmodel_start(); it's handled by the module framework. That
said, the module framework was adjusted to properly load secmodels
early during system startup.
- Adapt rump to changes: Instead of using empty stubs for securelevel,
simply use the suser secmodel. Also replace secmodel_start() with a
call to secmodel_suser_start().
- 5.99.20.
Testing was done on i386 ("release" build). Spearated module_init()
changes were tested on sparc and sparc64 as well by martin@ (thanks!).
Mailing list reference:
http://mail-index.netbsd.org/tech-kern/2009/09/25/msg006135.html
driver, gpiolock(4), is provided as an example how to interface real hardware.
A new securemodel, securemodel_keylock, is provided to show how this can
be used to tie keylocks to overall system security. This is experimental
code. The diff has been on tech-kern for several weeks.
Reviewed by many, kauth(9) integration reviewed by Elad Efrat; approved by
tonnerre@ and tron@. Thanks to everyone who provided feedback.
some requests to the device scope:
KAUTH_DEVICE_BLUETOOTH_SEND_COMMAND
KAUTH_DEVICE_BLUETOOTH_RECV_COMMAND
KAUTH_DEVICE_BLUETOOTH_RECV_EVENT
KAUTH_DEVICE_BLUETOOTH_RECV_DATA
and a listener tied to the HCI protocol that will approve the basic
minimum to be sent and received.
handle the requests in the bsd44_suser listener by approving all
when the credential is root.
operations, specifically quota and block allocation from reserved space.
Modify ufs_quotactl() to accomodate passing "mp" earlier by vfs_busy()ing
it a little bit higher.
Mailing list reference:
http://mail-index.netbsd.org/tech-kern/2009/04/26/msg004936.html
Note that the umapfs request mentioned in this thread was NOT added as
there is still on-going discussion regarding the proper implementation.
