**Contents**

[[!toc levels=3]]

#  Introduction 

Kernel security levels have been introduced back in 4.4 to use file flags as a mechanism to enhance security. Ususally the system is running at a level 1, which can be checked with **sysctl kern.securelevel**, once the level has been set in the bootup process using the securelevel option in **/etc/rc.conf** you cannot lower the level anymore, but you are allowed to raise it to either 1 or 2. 

The [[basics/sysctl]] variable kern.securelevel is a variable that is usually -1 or 0, and can be raised during normal operation to disallow certain operations in the filesystem to increase security. 


#  Securelevel restrictions 

secmodel_bsd44(9) defines the following restrictions: 

##  -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), systrace(4), or procfs. 
  * Immutable and append-only file flags may be changed 
  * All devices may be read or written subject to their permissions 

_Note: You can't run X11 with legacy (e.g. VESA) drivers above this securelevel_

_Try [sysutils/aperture](http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/pkgsrc/sysutils/aperture/) if you really need it._


##  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 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_
  * 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 

#  Examining and changing securelevel 

As a user, you can see the current value of securelevel: 
    
    $ sysctl kern.securelevel
    kern.securelevel = -1
    

But of course, you cannot change it: 
    
    $ sysctl -w kern.securelevel=0
    sysctl: kern.securelevel: sysctl() failed with Operation not permitted
    

You need to be root to do that: 
    
    # sysctl -w kern.securelevel=1
    kern.securelevel: -1 -> 1
    

Once it is set, its value can never be set to a lower value again: 
    
    # sysctl -w kern.securelevel=-1
    sysctl: kern.securelevel: sysctl() failed with Operation not permitted
    

... except by the kernel debugger, which you can enter at the console. On i386, press <Alt>+<Ctrl>+<ESC>: 
    
    db> w/l securelevel (-1)
    netbsd:securelevel   0x1 -> 0xffffffff
    db> c
    

#  Setting securelevel permanently 

The securelevel can be set after booting the system by setting the securelevel shell variable in /etc/rc.conf (see [[manpage]]). 


#  See also 

  * <http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/security.html#SECURELEVEL>