securelevel security model
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
, by providing convenient means of
“locking down” a system to a degree suited to its environment.
can raise the
Four security levels are provided:
- -1 Permanently insecure mode
- Do not raise the securelevel on
- 0 Insecure mode
- The init process (PID 1) may not be traced or accessed by
- Immutable and append-only file flags may be changed by
or by other means.
- All devices may be read or written subject to their permissions.
pins can be set and device drivers can be attached to them.
- On architectures that support
kernel modules can be loaded and unloaded.
- 1 Secure mode
- All effects of securelevel 0.
memory files /dev/mem and
/dev/kmem may not be written
- 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
variables may be changed.
- Adding or removing
nodes is denied.
- The RTC offset may not be changed.
- Set-id coredump settings may not be altered.
- 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.
- 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
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
single-user and in securelevel
multi-user. If a higher securelevel
while running multi-user, it can be set using the
keyword in the startup script
for details. Lower securelevels require the kernel to be compiled with
, causing it to always default to
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
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
variables are exported:
- The system security level. This level may be raised by processes with
appropriate privilege. It may only be lowered by process 1 (init).
evaluation routine to test whether the current
is above a certain threshold level or
The parameters to
- the unique identifier of
- a string,
- a reference to an
int representing the
- a boolean, set by
true when the
securelevel is strictly above the threshold
If successful, the evaluation returns 0 with the
argument being either
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
settings available only at security level 0 or lower.