Moved descriptions of securelevels from init(7) to security(7).

Files used both "securelevel" and either "secure level" or
"security level"; all are now "security level".

PR:             docs/84266
Submitted by:   garys
Approved by:    keramida
MFC after:      3 days

sbin/init/init.8

@@ -87,58 +87,9 @@ The password check is skipped if the
 is marked as
 .Dq secure .
 .Pp
-The kernel runs with five different levels of security.
-Any super-user process can raise the security level, but no process
-can lower it.
-The security levels are:
-.Bl -tag -width flag
-.It Ic -1
-Permanently insecure mode \- always run the system in level 0 mode.
-This is the default initial value.
-.It Ic 0
-Insecure mode \- immutable and append-only flags may be turned off.
-All devices may be read or written subject to their permissions.
-.It Ic 1
-Secure mode \- the system immutable and system append-only flags may not
-be turned off;
-disks for mounted file systems,
-.Pa /dev/mem ,
-.Pa /dev/kmem
-and
-.Pa /dev/io
-(if your platform has it) may not be opened for writing;
-kernel modules (see
-.Xr kld 4 )
-may not be loaded or unloaded.
-.It Ic 2
-Highly secure mode \- same as secure mode, plus disks may not be
-opened for writing (except by
-.Xr mount 2 )
-whether mounted or not.
-This level precludes tampering with file systems by unmounting them,
-but also inhibits running
-.Xr newfs 8
-while the system is multi-user.
-.Pp
-In addition, kernel time changes are restricted to less than or equal to one
-second.
-Attempts to change the time by more than this will log the message
-.Dq Time adjustment clamped to +1 second .
-.It Ic 3
-Network secure mode \- same as highly secure mode, plus
-IP packet filter rules (see
-.Xr ipfw 8 ,
-.Xr ipfirewall 4
-and
-.Xr pfctl 8 )
-cannot be changed and
-.Xr dummynet 4
-or
-.Xr pf 4
-configuration cannot be adjusted.
-.El
-.Pp
-If the security level is initially nonzero, then
+If the system security level (see
+.Xr security 7 )
+is initially nonzero, then
 .Nm
 leaves it unchanged.
 Otherwise,
@@ -161,9 +112,7 @@ is run in a jail, the security level of the
 .Dq host system
 will not be effected.
 Part of the information set up in the kernel to support a jail
-is a per-jail
-.Dq securelevel
-setting.
+is a per-jail security level.
 This allows running a higher security level inside of a jail
 than that of the host system.
 See
@@ -392,19 +341,13 @@ a persistent device error condition.
 .Xr kill 1 ,
 .Xr login 1 ,
 .Xr sh 1 ,
-.Xr dummynet 4 ,
-.Xr ipfirewall 4 ,
-.Xr kld 4 ,
-.Xr pf 4 ,
 .Xr ttys 5 ,
-.Xr crash 8 ,
 .Xr getty 8 ,
 .Xr halt 8 ,
-.Xr ipfw 8 ,
 .Xr jail 8 ,
-.Xr pfctl 8 ,
 .Xr rc 8 ,
 .Xr reboot 8 ,
+.Xr security 7 ,
 .Xr shutdown 8 ,
 .Xr sysctl 8
 .Sh HISTORY

share/man/man7/security.7

@@ -498,14 +498,14 @@ his own
 .Xr bpf 4
 device or other sniffing device on a running kernel.
 To avoid these problems you have to run
-the kernel at a higher secure level, at least securelevel 1.
-The securelevel can be set with a
+the kernel at a higher security level, at least level 1.
+The security level can be set with a
 .Xr sysctl 8
 on the
 .Va kern.securelevel
 variable.
 Once you have
-set the securelevel to 1, write access to raw devices will be denied and
+set the security level to 1, write access to raw devices will be denied and
 special
 .Xr chflags 1
 flags, such as
@@ -515,12 +515,12 @@ You must also ensure
 that the
 .Cm schg
 flag is set on critical startup binaries, directories, and
-script files \(em everything that gets run up to the point where the securelevel
-is set.
+script files \(em everything that gets run
+up to the point where the security level is set.
 This might be overdoing it, and upgrading the system is much more
-difficult when you operate at a higher secure level.
+difficult when you operate at a higher security level.
 You may compromise and
-run the system at a higher secure level but not set the
+run the system at a higher security level but not set the
 .Cm schg
 flag for every
 system file and directory under the sun.
@@ -533,6 +533,62 @@ read-only.
 It should be noted that being too draconian in
 what you attempt to protect may prevent the all-important detection of an
 intrusion.
+.Pp
+The kernel runs with five different security levels.
+Any super-user process can raise the level, but no process
+can lower it.
+The security levels are:
+.Bl -tag -width flag
+.It Ic -1
+Permanently insecure mode \- always run the system in insecure mode.
+This is the default initial value.
+.It Ic 0
+Insecure mode \- immutable and append-only flags may be turned off.
+All devices may be read or written subject to their permissions.
+.It Ic 1
+Secure mode \- the system immutable and system append-only flags may not
+be turned off;
+disks for mounted file systems,
+.Pa /dev/mem ,
+.Pa /dev/kmem
+and
+.Pa /dev/io
+(if your platform has it) may not be opened for writing;
+kernel modules (see
+.Xr kld 4 )
+may not be loaded or unloaded.
+.It Ic 2
+Highly secure mode \- same as secure mode, plus disks may not be
+opened for writing (except by
+.Xr mount 2 )
+whether mounted or not.
+This level precludes tampering with file systems by unmounting them,
+but also inhibits running
+.Xr newfs 8
+while the system is multi-user.
+.Pp
+In addition, kernel time changes are restricted to less than or equal to one
+second.
+Attempts to change the time by more than this will log the message
+.Dq Time adjustment clamped to +1 second .
+.It Ic 3
+Network secure mode \- same as highly secure mode, plus
+IP packet filter rules (see
+.Xr ipfw 8 ,
+.Xr ipfirewall 4
+and
+.Xr pfctl 8 )
+cannot be changed and
+.Xr dummynet 4
+or
+.Xr pf 4
+configuration cannot be adjusted.
+.El
+.Pp
+The security level is discussed further in
+.Xr init 8
+and can be configured with variables documented in
+.Xr rc.conf 8 .
 .Sh CHECKING FILE INTEGRITY: BINARIES, CONFIG FILES, ETC
 When it comes right down to it, you can only protect your core system
 configuration and control files so much before the convenience factor