On Tue, Aug 19, 2003 at 09:52:00AM -0700, Michael Halcrow wrote:
> Whoever or whatever is authorized to do so in *BSD's implementation.
> If anyone knows the best answer to this, please don't hesitate to let
> me know. Meanwhile, I'm going to keep researching this.
securelevel(7) from my OpenBSD machine. Note that it doesn't mention
anything about rebooting the system. :)
Another thing to consider: /sbin/shutdown, or telinit 0, telinit 6, etc,
kill and mangle a -lot- of processes on the way down -- do you really
want to prevent the reboot(2) at the end of all that process if your
securelevels deal isn't properly twitched?
And one last item to consider; Robb, from IBM's LTC, was working on a
securelevels implementation for LSM. I don't think he is with the LTC
any longer, but perhaps his module is still wending its way through the
byzintine IBM legal system to get an IBM/GPL Stamp Of Approval.
Cheers :)
SECURELEVEL(7) OpenBSD Reference Manual SECURELEVEL(7)
NAME
securelevel - securelevel and its effects
SYNOPSIS
The OpenBSD kernel provides four levels of system security:
-1 Permanently insecure mode
- init(8) will not attempt to raise the securelevel
- may only be set with sysctl(8) while the system is insecure
- otherwise identical to securelevel 0
0 Insecure mode
- used during bootstrapping and while the system is single-user
- all devices may be read or written subject to their permissions
- system file flags may be cleared
1 Secure mode
- default mode when system is multi-user
- securelevel may no longer be lowered except by init
- /dev/mem and /dev/kmem may not be written to
- raw disk devices of mounted file systems are read-only
- system immutable and append-only file flags may not be removed
- kernel modules may not be loaded or unloaded
2 Highly secure mode
- all effects of securelevel 1
- raw disk devices are always read-only whether mounted or not
- settimeofday(2) may not set the time backwards
- pfctl(8) may no longer alter filter or nat rules
- the ddb.console and ddb.panic sysctl(8) variables may not be
raised
DESCRIPTION
Securelevel provides convenient means of ``locking down'' a system to a
degree suited to its environment. It is normally set at boot via the
rc.securelevel(8) script, or the superuser may raise securelevel at any
time by modifying the kern.securelevel sysctl(8) variable. However, only
init(8) may lower it once the system has entered secure mode. A kernel
built with option INSECURE in the config file will default to permanently
insecure mode.
Highly secure mode may seem Draconian, but is intended as a last line of
defence should the superuser account be compromised. Its effects pre-
clude circumvention of file flags by direct modification of a raw disk
device, or erasure of a file system by means of newfs(8). Further, it can
limit the potential damage of a compromised ``firewall'' by prohibiting
the modification of packet filter rules. Preventing the system clock
from being set backwards aids in post-mortem analysis and helps ensure
the integrity of logs. Precision timekeeping is not affected because the
clock may still be slowed.
Because securelevel can be modified with the in-kernel debugger ddb(4), a
convenient means of locking it off (if present) is provided on highly se-
cure systems. This is accomplished by setting ddb.console and ddb.panic
to 0 with the sysctl(8) utility.
FILES
/etc/rc.securelevel commands that run before the security level changes
SEE ALSO
chflags(2), settimeofday(2), mem(4), options(4), init(8), rc(8),
sysctl(8)
HISTORY
The securelevel manual page first appeared in OpenBSD 2.6.
BUGS
The list of securelevel's effects may not be comprehensive.
OpenBSD 3.1 January 4, 2000 2
--
Too bad life doesn't have a :q! command.
This archive was generated by hypermail 2b30 : Tue Aug 19 2003 - 09:05:00 PDT