- NetBSD Manual Pages
SECMODEL_BSD44(9) NetBSD Kernel Developer's Manual SECMODEL_BSD44(9)
Powered by man-cgi (2021-06-01).
Maintained for NetBSD
by Kimmo Suominen.
Based on man-cgi by Panagiotis Christias.
secmodel_bsd44 -- traditional NetBSD security model (based on 4.4BSD)
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.
secmodel_bsd44 provides four levels of securelevel, defined as follows:
-1 Permanently insecure mode
- Don't 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
- All devices may be read or written subject to their permissions
1 Secure mode
- All effects of securelevel 0
- /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
- The net.inet.ip.sourceroute sysctl(8) variable may not be
- 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
- Device ``pass-thru'' requests that may be used to perform raw
disk and/or memory access are denied
- iopl and ioperm calls are denied
- Access to unmanaged memory is denied
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
Highly secure mode may seem Draconian, but is intended as a last line of
defence should the superuser account be compromised. Its effects pre-
clude 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 prohibit-
ing 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 pro-
grams 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
kauth(9), secmodel(9), secmodel_bsd44(9)
Elad Efrat <elad@NetBSD.org>
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
NetBSD 5.0 November 21, 2007 NetBSD 5.0