1.\" $NetBSD: secmodel_bsd44.9,v 1.8 2006/11/22 21:00:30 elad Exp $ 2.\" 3.\" Copyright (c) 2006 Elad Efrat <elad@NetBSD.org> 4.\" All rights reserved. 5.\" 6.\" Redistribution and use in source and binary forms, with or without 7.\" modification, are permitted provided that the following conditions 8.\" are met: 9.\" 1. Redistributions of source code must retain the above copyright 10.\" notice, this list of conditions and the following disclaimer. 11.\" 2. Redistributions in binary form must reproduce the above copyright 12.\" notice, this list of conditions and the following disclaimer in the 13.\" documentation and/or other materials provided with the distribution. 14.\" 3. All advertising materials mentioning features or use of this software 15.\" must display the following acknowledgement: 16.\" This product includes software developed by Elad Efrat. 17.\" 4. The name of the author may not be used to endorse or promote products 18.\" derived from this software without specific prior written permission. 19.\" 20.\" THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR 21.\" IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES 22.\" OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. 23.\" IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, 24.\" INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT 25.\" NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 26.\" DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 27.\" THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 28.\" (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF 29.\" THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 30.\" 31.Dd November 22, 2006 32.Dt SECMODEL_BSD44 9 33.Os 34.Sh NAME 35.Nm secmodel_bsd44 36.Nd traditional 37.Nx 38security model (based on 39.Bx 4.4 ) 40.Sh SYNOPSIS 41.In secmodel/bsd44/bsd44.h 42.In secmodel/bsd44/securelevel.h 43.In secmodel/bsd44/suser.h 44.Sh DESCRIPTION 45.Nm 46is the default security model in 47.Nx . 48It is the traditional security model based on 49.Bx 4.4 50and is composed of two main concepts, the 51.Em super-user 52and the 53.Em securelevel . 54.Ss Super-user 55The 56.Em super-user 57is the host administrator, considered to have higher privileges than other 58users. 59It is the only entity the kernel recognizes by having an effective user-id 60of zero. 61.Ss Securelevel 62The securelevel mechanism is intended to allow protecting the persistance 63of code and data on the system, or a subset thereof, from modification, even 64by the super-user, by providing convenient means of 65.Dq locking down 66a system to a degree suited to its environment. 67.Pp 68The super-user can raise the securelevel using 69.Xr sysctl 8 , 70but only 71.Xr init 8 72can lower it. 73.Pp 74.Nm 75provides four levels of securelevel, defined as follows: 76.Bl -tag -width flag 77.It \&-1 Em Permanently insecure mode 78.Bl -hyphen -compact 79.It 80Don't raise the securelevel on boot 81.El 82.It \ 0 Em Insecure mode 83.Bl -hyphen -compact 84.It 85The init process (PID 1) may not be traced or accessed by 86.Xr ptrace 2 , 87.Xr systrace 4 , 88or procfs. 89.It 90Immutable and append-only file flags may be changed 91.It 92All devices may be read or written subject to their permissions 93.It 94Access to unmanaged memory on x86 and alpha is denied 95.El 96.It \ 1 Em Secure mode 97.Bl -hyphen -compact 98.It 99All effects of securelevel 0 100.It 101.Pa /dev/mem 102and 103.Pa /dev/kmem 104may not be written to 105.It 106Raw disk devices of mounted file systems are read-only 107.It 108Immutable and append-only file flags may not be removed 109.It 110Kernel modules may not be loaded or unloaded 111.It 112The 113.Va net.inet.ip.sourceroute 114.Xr sysctl 8 115variable may not be changed 116.It 117Adding or removing 118.Xr sysctl 9 119nodes is denied 120.It 121The RTC offset may not be changed 122.It 123Set-id coredump settings may not be altered 124.It 125Attaching the IP-based kernel debugger, 126.Xr ipkdb 4 , 127is not allowed 128.It 129Device 130.Dq pass-thru 131requests that may be used to perform raw disk and/or memory access are denied 132.It 133x86 134.Em iopl 135and 136.Em ioperm 137calls are denied 138.El 139.It \ 2 Em Highly secure mode 140.Bl -hyphen -compact 141.It 142All effects of securelevel 1 143.It 144Raw disk devices are always read-only whether mounted or not 145.It 146New disks may not be mounted, and existing mounts may only be downgraded 147from read-write to read-only 148.It 149The system clock may not be set backwards or close to overflow 150.It 151Per-process coredump name may not be changed 152.It 153Packet filtering and NAT rules may not be altered 154.El 155.El 156.Pp 157Highly secure mode may seem Draconian, but is intended as a last line of 158defence should the superuser account be compromised. 159Its effects preclude 160circumvention of file flags by direct modification of a raw disk device, 161or erasure of a file system by means of 162.Xr newfs 8 . 163Further, it can limit the potential damage of a compromised 164.Dq firewall 165by prohibiting the modification of packet filter rules. 166Preventing 167the system clock from being set backwards aids in post-mortem analysis 168and helps ensure the integrity of logs. 169Precision timekeeping is not 170affected because the clock may still be slowed. 171.Pp 172Normally, the system runs in securelevel 0 while single-user and in 173securelevel 1 while multi-user. 174If a higher securelevel is desired while running multi-user, 175it can be set using the 176.Em securelevel 177keyword in the startup script 178.Pa /etc/rc.conf , 179see 180.Xr rc.conf 5 181for details. 182Lower securelevels require the kernel to be compiled with 183.Sy options INSECURE , 184causing it to always default to securelevel \-1. 185.Pp 186In order for this protection to be effective, the administrator 187must ensure that no program that is run while the security level 188is 0 or lower, nor any data or configuration file used by any such 189program, can be modified while the security level is greater than 1900. 191This may be achieved through the careful use of the 192.Dq immutable 193file flag to define and protect a Trusted Computing Base (TCB) 194consisting of all such programs and data, or by ensuring that all 195such programs and data are on filesystems that are mounted read-only 196and running at security level 2 or higher. 197.Em Particular care must be taken to ensure, if relying upon 198.Em security level 1 and the use of file flags, that the integrity of the 199.Em TCB cannot be compromised through the use of modifications to the 200.Em disklabel or access to overlapping disk partitions, including the 201.Em raw partition . 202.Pp 203Do not overlook the fact that shell scripts (or anything else fed to an 204interpreter, through any mechanism) and the kernel itself are "programs 205that run while the security level is 0" and must be considered part of 206the TCB. 207.Sh SEE ALSO 208.Xr kauth 9 , 209.Xr secmodel 9 210.Sh AUTHORS 211.An Elad Efrat Aq elad@NetBSD.org 212.Sh BUGS 213Systems without 214.Xr sysctl 8 215behave as though they have security level \-1. 216.Pp 217The security level 2 restrictions relating to TCB integrity protection 218should be enforced at security level 1. 219Restrictions dependent upon security level but not relating to TCB 220integrity protection should be selected by 221.Xr sysctl 8 222settings available only at security level 0 or lower. 223