A type specifier of the form
enum identifier
without an enumerator list shall only appear after the type it
specifies is complete.
which means that we cannot pass an "enum vtype" argument to
kauth_access_action() without fully specifying the type first.
Unfortunately there is a complicated include file loop which
makes that difficult, so convert this minimal function into a
macro (and capitalize it).
(ok elad@)
allows registration of callbacks that can be used later for
cross-secmodel "safe" communication.
When a secmodel wishes to know a property maintained by another
secmodel, it has to submit a request to it so the other secmodel can
proceed to evaluating the request. This is done through the
secmodel_eval(9) call; example:
bool isroot;
error = secmodel_eval("org.netbsd.secmodel.suser", "is-root",
cred, &isroot);
if (error == 0 && !isroot)
result = KAUTH_RESULT_DENY;
This one asks the suser module if the credentials are assumed to be root
when evaluated by suser module. If the module is present, it will
respond. If absent, the call will return an error.
Args and command are arbitrarily defined; it's up to the secmodel(9) to
document what it expects.
Typical example is securelevel testing: when someone wants to know
whether securelevel is raised above a certain level or not, the caller
has to request this property to the secmodel_securelevel(9) module.
Given that securelevel module may be absent from system's context (thus
making access to the global "securelevel" variable impossible or
unsafe), this API can cope with this absence and return an error.
We are using secmodel_eval(9) to implement a secmodel_extensions(9)
module, which plugs with the bsd44, suser and securelevel secmodels
to provide the logic behind curtain, usermount and user_set_cpu_affinity
modes, without adding hooks to traditional secmodels. This solves a
real issue with the current secmodel(9) code, as usermount or
user_set_cpu_affinity are not really tied to secmodel_suser(9).
The secmodel_eval(9) is also used to restrict security.models settings
when securelevel is above 0, through the "is-securelevel-above"
evaluation:
- curtain can be enabled any time, but cannot be disabled if
securelevel is above 0.
- usermount/user_set_cpu_affinity can be disabled any time, but cannot
be enabled if securelevel is above 0.
Regarding sysctl(7) entries:
curtain and usermount are now found under security.models.extensions
tree. The security.curtain and vfs.generic.usermount are still
accessible for backwards compat.
Documentation is incoming, I am proof-reading my writings.
Written by elad@, reviewed and tested (anita test + interact for rights
tests) by me. ok elad@.
See also
http://mail-index.netbsd.org/tech-security/2011/11/29/msg000422.html
XXX might consider va0 mapping too.
XXX Having a secmodel(9) specific printf (like aprint_*) for reporting
secmodel(9) errors might be a good idea, but I am not sure on how
to design such a function right now.
we no longer need to guard against access from hardware interrupt handlers.
Additionally, if cloning a process with CLONE_SIGHAND, arrange to have the
child process share the parent's lock so that signal state may be kept in
sync. Partially addresses PR kern/37437.
(xxx_INIT to xxx_HEAD_INITIALIZER). Drop code which inits
non-auto (global or static) variables to 0 since that's
already implied by being non-auto. Init some static/global
cpu_simple_locks at compile time.
can copy directly to/from userspace.
Avoids exposing the implementation of the group list as an array to code
outside kern_auth.c.
compat code and man page need updating.
Exposed that the kauth code holds groups in an array, but removes some
of the knowledge of the maximum number of groups.
Allows the syscall code to copyin/out directly to/from the cred structure,
this save a lot of faffing about with malloc/free even when compat code
has to use 16bit groups.
(depracted some time ago) 'struct kinfo_proc' returned by sysctl.
Move the definitions to sys/syctl.h and rename in order to ensure all the
users are located.
implementation and meant to be used by security models to hook credential
related operations (init, fork, copy, free -- hooked in kauth_cred_alloc(),
kauth_proc_fork(), kauth_cred_clone(), and kauth_cred_free(), respectively)
and document it.
Add specificdata to credentials, and routines to register/deregister new
"keys", as well as set/get routines. This allows security models to add
their own private data to a kauth_cred_t.
The above two, combined, allow security models to control inheritance of
their own private data in credentials which is a requirement for doing
stuff like, I dunno, capabilities?
undocumented) and change logic in kauth_authorize_action() to only
allow an action if it wasn't explicitly allowed/denied and there are no
secmodels loaded.
Okay yamt@.
requests and centralizing them all. The result is that some of these
are not used on some architectures, but the documentation was updated
to reflect that.
recent bugs introduced with the usage of kauth(9) in MD/device code.
While here, change the sanity checks to KASSERT(), because they're really
bugs we should fix if triggered.
