Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
SECMODEL_SECURELEVE... FreeBSD Kernel Developer's ManualSECMODEL_SECURELEVE...

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

	   +o   Do not raise the	securelevel on boot.

      0	Insecure mode

	   +o   The init	process	(PID 1)	may not	be traced or accessed by
	       ptrace(2) or procfs.

	   +o   Immutable and append-only file flags may	be changed by
	       chflags(1) or by	other means.

	   +o   All devices may be read or written subject to their permis-
	       sions.

	   +o   All gpio(4) pins	can be set and device drivers can be attached
	       to them.

	   +o   On architectures	that support module(7),	kernel modules can be
	       loaded and unloaded.

      1	Secure mode

	   +o   All effects of securelevel 0.

	   +o   The x86/kmem(4) memory files /dev/mem and /dev/kmem may not be
	       written to.

	   +o   Raw disk	devices	of mounted file	systems	are read-only.

	   +o   Immutable and append-only file flags may	not be removed.

	   +o   Kernel modules may not be loaded	or unloaded.

	   +o   Neither the net.inet.ip.sourceroute nor the vm.user_va0_disable
	       sysctl(8) variables may be changed.

	   +o   Adding or removing sysctl(9) nodes is denied.

	   +o   The RTC offset may not be changed.

	   +o   Set-id coredump settings	may not	be altered.

	   +o   Device "pass-thru" requests that	may be used to perform raw
	       disk and/or memory access are denied.

	   +o   The iopl	and ioperm calls are denied.

	   +o   Access to unmanaged memory is denied.

	   +o   Only GPIO pins that have	been set at securelevel	0 can be ac-
	       cessed.

      2	Highly secure mode

	   +o   All effects of securelevel 1.

	   +o   Raw disk	devices	are always read-only whether mounted or	not.

	   +o   New disks may not be mounted, and existing mounts may only be
	       downgraded from read-write to read-only.

	   +o   The system clock	may not	be set backwards or close to overflow.

	   +o   Per-process coredump name may not be changed.

	   +o   Packet filtering	and NAT	rules may not be altered.

	   +o   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	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 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 se-
     curelevels	require	the kernel to be compiled with options INSECURE, caus-
     ing it to always default to securelevel -1.

     In	order for this protection to be	effective, the administrator must en-
     sure 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 modi-
     fied while	the security level is greater than 0.  This may	be achieved
     through the careful use of	the "immutable"	file flag to define and	pro-
     tect 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 pro-
	      cesses 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 other-
	    wise.

RETURN TYPES
     If	successful, the	evaluation returns 0 with the ret argument being ei-
     ther 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 se-
     curity level but not relating to TCB integrity protection should be se-
     lected by sysctl(8) settings available only at security level 0 or	lower.

FreeBSD	13.0			 May 18, 2019			  FreeBSD 13.0

NAME | DESCRIPTION | FUNCTIONS | RETURN TYPES | SEE ALSO | AUTHORS | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=secmodel_securelevel&sektion=9&manpath=NetBSD+9.1>

home | help