]> CyberLeo.Net >> Repos - FreeBSD/releng/10.0.git/blob - usr.sbin/bsdconfig/security/include/securelevel.hlp
- Copy stable/10 (r259064) to releng/10.0 as part of the
[FreeBSD/releng/10.0.git] / usr.sbin / bsdconfig / security / include / securelevel.hlp
1 This menu allows you to configure the Securelevel mechanism in FreeBSD.
2
3 Securelevels may be used to limit the privileges assigned to the
4 root user in multi-user mode, which in turn may limit the effects of
5 a root compromise, at the cost of reducing administrative functions.
6 Refer to the security(7) and init(8) manual pages for complete details.
7
8    -1    Permanently insecure mode - always run the system in level 0
9          mode.  This is the default initial value.
10
11    0     Insecure mode - immutable and append-only flags may be turned
12          off.  All devices may be read or written subject to their
13          permissions.
14
15    1     Secure mode - the system immutable and system append-only
16          flags may not be turned off; disks for mounted file systems,
17          /dev/mem, /dev/kmem and /dev/io (if your platform has it)
18          may not be opened for writing; kernel modules (see kld(4))
19          may not be loaded or unloaded.
20
21    2     Highly secure mode - same as secure mode, plus disks may not
22          be opened for writing (except by mount(2)) whether mounted or
23          not.  This level precludes tampering with file systems by
24          unmounting them, but also inhibits running newfs(8) while the
25          system is multi-user.
26
27          In addition, kernel time changes are restricted to less than
28          or equal to one second.  Attempts to change the time by more
29          than this will log the message ``Time adjustment clamped to +1
30          second''.
31
32    3     Network secure mode - same as highly secure mode, plus IP
33          packet filter rules (see ipfw(8), ipfirewall(4) and pfctl(8))
34          cannot be changed and dummynet(4) or pf(4) configuration
35          cannot be adjusted.
36
37 Securelevels must be used in combination with careful system design and
38 application of protective mechanisms to prevent system configuration
39 files from being modified in a way that compromises the protections of
40 the securelevel variable upon reboot.