SECMODEL(9) | NetBSD Kernel Developer's Manual | SECMODEL(9) |
It is possible to modify the security model -- either slightly or using an entirely different model -- by attaching/detaching kauth(9) listeners. This document describes this process.
The problem with the above is that the interface ("can X do Y?") was tightly coupled with the implementation ("is X Z?"). kauth(9) allowed us to separate them, dispatching requests with highly detailed context using a consistent and clear KPI.
The result is a pluggable framework for attaching "listeners" that can modify the behavior of the system, security-wise. It allows us to maintain the existing security model (based on a single superuser and above-superuser restrictions known as securelevel) but easily decouple it from the system, given we want to use a different one.
The different security model can be implemented in the kernel or loaded as a module, base its decisions on available information, dispatch the decision to a userspace daemon, or even to a centralized network authorization server.
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):
If the security model is to be started automatically by the kernel and is compiled in it, a function called secmodel_start() can be added to call the model's start routine.
If the security model is to be built and used as a module, another function called secmodel_<model>_stop(), to stop the security model in case the module is to be unloaded.
All "knobs" for the model should be located under the new node, as well as a mandatory "name" variable, indicating a descriptive human-readable name for the model.
If the module is to be used as a module, explicit calls to the setup routine and sysctl_teardown() are to be used to create and destroy the sysctl(9) tree.
Below is sample code for a kauth(9) network scope listener for the jenna security model. It is used to allow users with a user-id below 1000 bind to reserved ports (for example, 22/TCP):
int secmodel_jenna_network_cb(kauth_cred_t cred, kauth_action_t action, void *cookie, void *arg0, void *arg1, void *arg2, void *arg3) { int result; /* Default defer. */ result = KAUTH_RESULT_DEFER; switch (action) { case KAUTH_NETWORK_BIND: /* * We only care about bind(2) requests to privileged * ports. */ if ((u_long)arg0 == KAUTH_REQ_NETWORK_BIND_PRIVPORT) { /* * If the user-id is below 1000, which may * indicate a "reserved" user-id, allow the * request. */ if (kauth_cred_geteuid(cred) < 1000) result = KAUTH_RESULT_ALLOW; } break; } return (result); }
There are two main issues, however, with that listener, that you should be aware of when approaching to write your own security model:
That's why before implementing listeners, it should be clear whether they implement an entirely new from scratch security model, or add on-top of an existing one.
To properly "stack" minor adjustments on-top of an existing security model, one could use one of two approaches:
This requires the security model developer to add an internal scope for every scope the model partly covers, and registering the fall-back listeners to it. In the model's listener(s) for the scope, when a defer decision is made, the request is passed to be authorized on the internal scope, effectively using the fall-back security model.
Here's example code that implements the above:
#include <secmodel/bsd44/bsd44.h> /* * Internal fall-back scope for the network scope. */ #define JENNA_ISCOPE_NETWORK "jenna.iscope.network" static kauth_scope_t secmodel_jenna_iscope_network; /* * Jenna's entry point. Register internal scope for the network scope * which we partly cover for fall-back authorization. */ void secmodel_jenna_start(void) { secmodel_jenna_iscope_network = kauth_register_scope( JENNA_ISCOPE_NETWORK, NULL, NULL); kauth_listen_scope(JENNA_ISCOPE_NETWORK, secmodel_bsd44_suser_network_cb, NULL); kauth_listen_scope(JENNA_ISCOPE_NETWORK, secmodel_securelevel_network_cb, NULL); } /* * Jenna sits on top of another model, effectively filtering requests. * If it has nothing to say, it discards the request. This is a good * example for fine-tuning a security model for a special need. */ int secmodel_jenna_network_cb(kauth_cred_t cred, kauth_action_t action, void *cookie, void *arg0, void *arg1, void *arg2, void *arg3) { int result; /* Default defer. */ result = KAUTH_RESULT_DEFER; switch (action) { case KAUTH_NETWORK_BIND: /* * We only care about bind(2) requests to privileged * ports. */ if ((u_long)arg0 == KAUTH_REQ_NETWORK_BIND_PRIVPORT) { if (kauth_cred_geteuid(cred) < 1000) result = KAUTH_RESULT_ALLOW; } break; } /* * If we have don't have a decision, fall-back to the bsd44 * security model. */ if (result == KAUTH_RESULT_DEFER) result = kauth_authorize_action( secmodel_jenna_iscope_network, cred, action, arg0, arg1, arg2, arg3); return (result); }
int secmodel_jenna_network_cb(kauth_cred_t cred, kauth_action_t action, void *cookie, void *arg0, void *arg1, void *arg2, void *arg3) { int result; /* Default defer. */ result = KAUTH_RESULT_DEFER; switch (action) { case KAUTH_NETWORK_BIND: /* * We only care about bind(2) requests to privileged * ports. */ if ((u_long)arg0 == KAUTH_REQ_NETWORK_BIND_PRIVPORT) { if (kauth_cred_geteuid(cred) < 1000) result = KAUTH_RESULT_ALLOW; } break; } /* * If we have don't have a decision, fall-back to the bsd44 * security model's suser behavior. */ if (result == KAUTH_RESULT_DEFER) result = secmodel_bsd44_suser_network_cb(cred, action, cookie, arg0, arg1, arg2, arg3); return (result); }
To make it easier on developers to write new security models from scratch, NetBSD maintains skeleton listeners that contain every possible request and arguments.
May 10, 2009 | NetBSD 5.99 |