Before writing a new security model, one should be familiar with the
kauth(9) KPI, its limitations, requirements, and so on.
First, some terminology. According to
kauth(9), the system is logically divided to scopes, where each scope denotes a different area of interest in the system -- something like a namespace. For example,
NetBSD has the process, network, and machdep scopes, representing process-related, network-related, and machdep-related actions.
Each scope has a collection of actions -- or requests -- forming the high level indication of the request type. Each request is automatically associated with credentials and between zero to four arguments providing the request context.
For example, in the process scope there are requests such as "can signal", "can change rlimits", and "can change corename".
Each scope in the system is associated with listeners, which are actually callback routines, that get called when an authorization request on the relevant scope takes place.
Every listener receives the request and its context, and can make a decision of either "allow", "deny", or "defer" (if it doesn't want to be the one deciding).
It is important to note that a single "deny" is enough to fail a request, and at least a single "allow" is required to allow it. In other words, it is impossible to attach listeners that weaken the security of the system or override decisions made by other listeners.
At last, there are several things you should remember about
kauth(9):
–
Authorization requests can not be issued when the kernel is holding any locks. This is a requirement from kernel code, to allow designing security models where the request should be dispatched to userspace or a different host.
–
Private listener data -- such as internal data-structures -- is entirely under the responsibility of the developer. Locking, synchronization, and garbage collection are all things that
kauth(9) does
not take care of for you!