secmodel_securelevel man page on NetBSD

Man page or keyword search:  
man Server   9087 pages
apropos Keyword Search (all sections)
Output format
NetBSD logo
[printable version]

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

	   ·   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 permis‐
	       sions.

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

      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 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
     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
     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
     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
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server NetBSD

List of man pages available for NetBSD

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net