From owner-freebsd-hackers  Fri Aug  9 21:57:29 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id VAA03544
          for hackers-outgoing; Fri, 9 Aug 1996 21:57:29 -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 SMTP id VAA03530
          for <Hackers@freebsd.org>; Fri, 9 Aug 1996 21:57:19 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id OAA16556; Sat, 10 Aug 1996 14:54:58 +1000
Date: Sat, 10 Aug 1996 14:54:58 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199608100454.OAA16556@godzilla.zeta.org.au>
To: bde@zeta.org.au, jds@TracerTech.COM
Subject: Re: kern_mib.c:int securelevel = -1;
Cc: Hackers@freebsd.org, michaelh@cet.co.jp
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>#ifdef SOAPBOX_MODE

>Thus, the comment in the systm.h just gives a false sense of security to
>anyone who reads it, puts securelevel in bss, and sits back feeling better
>about it.

ISTR pointing this out in old mail :-).  This time, I deleted the bogus
text (about the bss) and rewrote the text that doesn't match reality to
the following:

 * 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.

This is the wrong place to document the internals of init(8) and init.8
is probably the wrong place to document kern.securelevel.  Currently,
the big comment in systm.h is more or less duplicated in init.8 (except
the part about the bss).  There are stupid bugs in both - systm.h refers
to sysctl(1) and says to patch `securelevel' in kern_sysctl.c (where it
no longer lives) while init.8 says to patch `securelevel' in param.c
(where it would now conflict with the default initialization).

>The impression I've gotten is that securelevel was put in to play with
>filesystem-level support for append-only and immutable files, rather than
>as a concerted effort to really make BSD more secure.

>IMHO.
>#endif

I think it's also to play with making BSD more secure.

Bruce