Unix/Linux Go Back    


NetBSD 6.1.5 - man page for secmodel_securelevel (netbsd section 9)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


SECMODEL_SECURELEVEL(9) 	  BSD Kernel Developer's Manual 	  SECMODEL_SECURELEVEL(9)

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 permissions.

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

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

      1 Secure mode

	   o   All effects of securelevel 0.

	   o   The 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) vari-
	       ables 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   Attaching the IP-based kernel debugger, ipkdb(4), is not allowed.

	   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 accessed.

      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 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, caus-
     ing 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 cur-
     rent 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.

BSD					 January 16, 2012				      BSD
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 12:35 PM.