This way we can provide weak rumpkern stubs that don't require
rumpvfs for things that are relevant to vfs, but if you do link
rumpvfs then you get the same logic in secmodel extensions.
securelevel=1 is supposed to be a reasonable default for normal
computers. This got in the way of ever getting entropy from a seed
on a machine with no HWRNG -- e.g., from another machine, or by
making the executive decision that what has been sampled is good
enough and issuing `head -c 32 < /dev/urandom > /dev/random'.
automate installation of sysctl nodes.
Note that there are still a number of device and pseudo-device modules
that create entries tied to individual device units, rather than to the
module itself. These are not changed.
Model this new sysctl(3) entry after "user_set_cpu_affinity" in the same
level of sysctl(3) switches.
Allow to read unconditionally Debug Registers (no change here). This is
convenient as even if a user of a debugger does not use hardware assisted
watchpoints/breakpoints, a debugger can still prompt these values to store
in an internal cache with context of registers. Reading them should have
no security concerns.
Add a paranoid MI switch that prohibits by default setting these registers
by a regular user (non-superuser). Make this switch disabled by default.
There are enough reserved bits out there to allow using them
unconditionally on hardened hosts.
Features shipped with Debug Registers are optional features in debuggers.
There is no reduction in elementary functionality.
Reviewed by <christos>
Sponsored by <The NetBSD Foundation>
They were mistakenly removed when curtain and securelevel moved to
secmodel_extensions(9).
Reported by tls@ on tech-security@.
XXX will ask for pull-up for -6.
Implemented and enabled via CPU_UCODE kernel config option
for x86 and Xen Dom0.
Tested on different AMD machines with different
CPU families.
ok wiz@ for the manpages
ok releng@
ok core@ via releng@
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.
secmodel module(7), so there is no point in calling suser/securelevel
routines from bsd44. This leads to unwanted cross-secmodel dependencies.
Do not call secmodel_bsd44_init() from secmodel_overlay_init(). Doing so
resets all curtain/securelevel values, which is not really needed when
loading an overlay filter.
Remove the secmodel_register/deregister comments, they will be
implemented differently in an upcoming patch.
ok elad@ (via private mail).
at system shutdown. Disable with random_seed=NO in rc.conf if desired.
Goes to some trouble to never load or save to network filesystems.
Entropy should really be loaded by the boot loader but I am still
sorting out how to pass it to the kernel.
riastradh