926571dfa7
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.
|
||
|---|---|---|
| .. | ||
| dev | ||
| fs | ||
| include | ||
| kern | ||
| librump | ||
| net | ||
| ldscript.rump | ||
| Makefile | ||
| Makefile.rump | ||
| README.dirs | ||
| TODO | ||
$NetBSD: README.dirs,v 1.11 2010/05/11 11:58:14 pooka Exp $
The following is a quick rundown of the current directory structure.
First, components in the kernel namespace, i.e. compiled with -D_KERNEL
sys/rump/librump - kernel runtime emulation
/rumpkern - kernel core, e.g. syscall, interrupt and lock support
/rumpcrypto - kernel cryptographic routines
/rumpdev - device support, e.g. autoconf subsystem
/rumpnet - networking support and sockets layer
/rumpvfs - file system support
sys/rump/include
/machine - used for architectures where the rump ABI is not yet the
same as the kernel module ABI. will eventually disappear
completely
/rump - rump headers installed to userspace
sys/rump/dev - device components, e.g. audio, raidframe, usb drivers
sys/rump/fs - file system components
/lib/lib${fs} - kernel file system code
sys/rump/net - networking components
/lib/libnet - subroutines from sys/net, e.g. route and if_ethersubr
/lib/libnetinet - TCP/IP
/lib/libvirtif - a virtual interface which uses host tap(4) to shovel
packets. This is used by netinet and if_ethersubr.
/lib/libsockin - implements PF_INET using host kernel sockets. This is
mutually exclusive with net, netinet and virtif.
The rest are out-of-kernel components (i.e. no -D_KERNEL)
related to rump.
hypercall interface:
src/lib/librumpuser
The "rumpuser" set of interfaces is used by rump to communicate
with the host.
Users:
src/lib
/libp2k - puffs-to-vfs adaption layer, userspace namespace
/libukfs - user kernel file system, a library to access file system
images (or devices) directly in userspace without going
through a system call and puffs. It provides a slightly
higher interface than pure rump syscalls.
src/usr.sbin/puffs
rump_$fs - userspace file system daemons using the kernel fs code
src/share/examples/rump
Various examples detailing use of rump in different scenarios.
These are provided source-only.