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.
- minor tweak to the handler example: it leaks 't' (on stack)
when passed to sysctl_lookup(9), as it copyout its content via
sysctl_data. That would not be the case if CTLFLAG_IMMEDIATE flag
was set for this node but the example does not preclude that.
current CPU, but for any CPU which may accept this event.
xen/xenevt.c: more use of atomic ops and locks where appropriate, and some
other SMP fixes. Handle all events on the primary CPU (may be revisited
later). Set/clear ci_evtmask[] for watched events.
This should fix the problems on dom0 kernels reported by jym@
xbdback_xenbus_destroy(). The second call will wait forever as the first
already caused the xbd thread to exit.
Have xbdback_disconnect() check if we're already disconnected and if so,
do nothing.
lock, because we are going to trigger a KASSERT. Also hold the lock
longer and take the proc lock for kpsignal(). Maybe we should add
mutex_steal() and mutex_return() for the debugger? Lock correction
suggestion from jmcneill.
during probing old drives like DK312C in OMRON LUNA machines.
I'll check this MSGIN xfer problem later.
(NO_MANUAL_XFER also caused hang on heavy load on hp300 with multiple drives)
- more verbose output if vfs.wapbl.verbose_commit >= 2.
namely, time taken for each DIOCCACHESYNC calls.
wapbl_flush: 1322826000.785245900 this transaction = 546304 bytes
wapbl_cache_sync: 1: dev 0x0 0.017572724
wapbl_cache_sync: 2: dev 0x0 0.007199825
wapbl_flush: 1322826011.860771302 this transaction = 431104 bytes
wapbl_cache_sync: 1: dev 0x0 0.019469753
wapbl_cache_sync: 2: dev 0x0 0.009473410
wapbl_flush: 1322829266.489154342 this transaction = 187904 bytes
wapbl_cache_sync: 1: dev 0x4 0.022270180
wapbl_cache_sync: 2: dev 0x4 0.030749402
- fix a comment.
