--- wikisrc/kernel_secure_levels.mdwn 2011/11/21 03:22:58 1.1
+++ wikisrc/kernel_secure_levels.mdwn 2012/02/05 07:14:36 1.2
@@ -1,97 +1,97 @@
-**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) defeines 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 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 ++:
-
- 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
-
- *
-
+**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) defeines 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 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 ++:
+
+ 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
+
+ *
+