From owner-freebsd-current  Sat Oct  5 22:01:38 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA12383
          for current-outgoing; Sat, 5 Oct 1996 22:01:38 -0700 (PDT)
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id WAA12377
          for <current@freebsd.org>; Sat, 5 Oct 1996 22:01:32 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id OAA10795; Sun, 6 Oct 1996 14:56:39 +1000
Date: Sun, 6 Oct 1996 14:56:39 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199610060456.OAA10795@godzilla.zeta.org.au>
To: current@freebsd.org, michaelh@cet.co.jp
Subject: Re: secure level diffs to kern_mib.c, LINT
Sender: owner-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>FreeBSD defaults securelevel to -1, use the following diffs if you prefer
>normal bsd operations or want a choice.  Man init(8) for details.

Use `sysctl -w kern.securelevel=0' in /etc/rc.local if you want the
BSD4.4Lite default.  If you want the securelevels > 0 to actually work,
then you must do considerably more to fix security holes in certain
device drivers.  If you want securelevels > 0 to be useful, then you
must do considerably more to make all critical system directories and
log files immutable or append-only, and be prepared to check and restore
all files on the system which aren't immutable if the log files show
that there may have been a breakin.

>systm.h also has securelevel related comments.  The note about securelevel
>initialization in .bss is controversial, please draw your own conclusions.

No, the part about the bss is just bogus.  I removed that part and rewrote
the rest of the comment to avoid documenting (previous) policy in systm.h.

Bruce

diff -c2 systm.h~ systm.h
*** systm.h~	Tue Oct  1 04:47:17 1996
--- systm.h	Sun Sep 15 07:33:36 1996
***************
*** 61,74 ****
   *	newfs while the system is secured.
   *
!  * In normal operation, the system runs in level 0 mode while single user
!  * and in level 1 mode while multiuser. If level 2 mode is desired while
!  * running multiuser, it can be set in the multiuser startup script
!  * (/etc/rc.local) using sysctl(1). If it is desired to run the system
!  * in level 0 mode while multiuser, initialize the variable securelevel
!  * in /sys/kern/kern_sysctl.c to -1. Note that it is NOT initialized to
!  * zero as that would allow the kernel binary to be patched to -1.
!  * Without initialization, securelevel loads in the BSS area which only
!  * comes into existence when the kernel is loaded and hence cannot be
!  * patched by a stalking hacker.
   */
  extern int securelevel;		/* system security level */
--- 61,71 ----
   *	newfs while the system is secured.
   *
!  * If `securelevel' is initially 0, then process 1 normally arranges to run
!  * the system in level 0 mode while single user and in level 1 mode while
!  * multiuser. If `securelevel' is initially -1, then process 1 normally
!  * leaves it unchanged, so that the system always runs in level 0 mode. In
!  * both cases, if a more secure mode is desired, it can be set using
!  * sysctl(8) in the multi-user startup script (/etc/rc.local) or earlier.
!  * Process 1 will then reduce the level to 0 if single user mode is resumed.
   */
  extern int securelevel;		/* system security level */