NAME
secmodel_securelevel —
securelevel
security model
DESCRIPTION
The securelevel mechanism is intended to allow protecting the persistence of
code and data on the system, or a subset thereof, from modification, even by
the
super-user, by providing convenient means of
“locking down” a system to a degree suited to its environment.
The
super-user can raise the
securelevel
using
sysctl(8), but only
init(8) can lower it.
Four security levels are provided:
-
-
- -1 Permanently
insecure mode
-
- Do not raise the securelevel on
boot.
-
-
- 0
Insecure mode
-
- The init process (PID 1) may not be traced or
accessed by ptrace(2) or
procfs.
- Immutable and append-only file flags may be changed
by chflags(1) or by
other means.
- All devices may be read or written subject to their
permissions.
- All
gpio(4) pins can be set
and device drivers can be attached to them.
- On architectures that support
module(4), kernel
modules can be loaded and unloaded.
-
-
- 1 Secure
mode
-
- All effects of securelevel 0.
- The
kmem(4) memory files
/dev/mem and /dev/kmem may not be
written to.
- Raw disk devices of mounted file systems are
read-only.
- Immutable and append-only file flags may not be
removed.
- Kernel modules may not be loaded or unloaded.
- Neither the
net.inet.ip.sourceroute nor the
vm.user_va0_disable
sysctl(8) variables may
be changed.
- Adding or removing
sysctl(9) nodes is
denied.
- The RTC offset may not be changed.
- Set-id coredump settings may not be altered.
- Attaching the IP-based kernel debugger,
ipkdb(4), is not
allowed.
- Device “pass-thru” requests that may be
used to perform raw disk and/or memory access are denied.
- The iopl and
ioperm calls are denied.
- Access to unmanaged memory is denied.
- Only GPIO pins that have been set at
securelevel 0 can be accessed.
- SVS (Separate Virtual Space) may not be disabled on
platforms that support it.
-
-
- 2 Highly
secure mode
-
- All effects of securelevel 1.
- Raw disk devices are always read-only whether
mounted or not.
- New disks may not be mounted, and existing mounts
may only be downgraded from read-write to read-only.
- The system clock may not be set backwards or close
to overflow.
- Per-process coredump name may not be changed.
- Packet filtering and NAT rules may not be
altered.
- CPU ucode loading is denied on platforms that
support it.
Highly secure mode may seem Draconian, but is intended as a last line of defence
should the
super-user account be compromised. Its effects
preclude circumvention of file flags by direct modification of a raw disk
device, or erasure of a file system by means of
newfs(8). Further, it can limit
the potential damage of a compromised “firewall” by prohibiting
the modification of packet filter rules. Preventing the system clock from
being set backwards aids in post-mortem analysis and helps ensure the
integrity of logs. Precision timekeeping is not affected because the clock may
still be slowed.
Normally, the system runs in
securelevel 0 while single-user
and in
securelevel 1 while multi-user. If a higher
securelevel is desired while running multi-user, it can be
set using the
securelevel keyword in the startup script
/etc/rc.conf, see
rc.conf(5) for details. Lower
securelevels require the kernel to be compiled with
options
INSECURE, causing it to always default to
securelevel
-1.
In order for this protection to be effective, the administrator must ensure that
no program that is run while the security level is 0 or lower, nor any data or
configuration file used by any such program, can be modified while the
security level is greater than 0. This may be achieved through the careful use
of the “immutable” file flag to define and protect a Trusted
Computing Base (TCB) consisting of all such programs and data, or by ensuring
that all such programs and data are on filesystems that are mounted read-only
and running at security level 2 or higher.
Particular care must
be taken to ensure, if relying upon security level 1 and the
use of file flags, that the integrity of the TCB cannot be
compromised through the use of modifications to the
disklabel or access to overlapping disk partitions, including
the raw partition.
Do not overlook the fact that shell scripts (or anything else fed to an
interpreter, through any mechanism) and the kernel itself are "programs
that run while the security level is 0" and must be considered part of
the TCB.
The following
sysctl(3) variables
are exported:
-
-
- security.models.securelevel.securelevel
- The system security level. This level may be raised by
processes with appropriate privilege. It may only be lowered by process 1
(init).
FUNCTIONS
secmodel_securelevel exposes a
secmodel_eval(9)
evaluation routine to test whether the current
securelevel
is above a certain threshold level or not.
The parameters to
secmodel_eval(9) are:
- id
- the unique identifier of
secmodel_securelevel:
“
org.netbsd.secmodel.securelevel
”.
- what
- a string,
“
is-securelevel-above
”.
- arg
- a reference to an
int
representing
the threshold level.
- ret
- a boolean, set by secmodel_securelevel to
true
when the securelevel is
strictly above the threshold level, false
otherwise.
RETURN TYPES
If successful, the evaluation returns 0 with the
ret
argument being either
true
or
false
.
SEE ALSO
kauth(9),
secmodel(9),
secmodel_bsd44(9),
secmodel_eval(9)
AUTHORS
Elad Efrat
<
elad@NetBSD.org>
BUGS
Systems without
sysctl(8) behave
as though they have security level -1.
The security level 2 restrictions relating to TCB integrity protection should be
enforced at security level 1. Restrictions dependent upon security level but
not relating to TCB integrity protection should be selected by
sysctl(8) settings available
only at security level 0 or lower.