From owner-freebsd-security  Sun Jun  9 22:07:35 1996
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id WAA25009
          for security-outgoing; Sun, 9 Jun 1996 22:07:35 -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 WAA24645
          for <freebsd-security@freebsd.org>; Sun, 9 Jun 1996 22:06:39 -0700 (PDT)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id PAA30985; Mon, 10 Jun 1996 15:02:17 +1000
Date: Mon, 10 Jun 1996 15:02:17 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199606100502.PAA30985@godzilla.zeta.org.au>
To: bde@zeta.org.au, taob@io.org, wollman@lcs.mit.edu
Subject: Re: Effects of kern.securelevel >= 0
Cc: freebsd-security@freebsd.org
Sender: owner-security@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

>>>     According to /sys/sys/systm.h, single user mode should be
>>> associated with kern.securelevel=0 and multiuser mode with
>>> kern.securelevel=1.  Should the default /etc/rc have the appropriate
>>> sysctl call?

>>No.  It is automatically increased by init if it starts out as >=0.
>>Like the comment in the file says, you should delete the initializer
>>in the source file if you want to enable security features.

I wrote:
>Which comment in which file?  You can set it in kern_mib.c but there is
>no comment there.  Wouldn't setting it to 0 in /etc/rc work the same?

The file is /sys/sys/systm.h.  Duh.  It actually says to change the
initializer to _disable_ security features.  It then says something
bogus about not using explicit initialization to 0 since then the value
would be in the kernel data instead of the bss and crhackers would be
able to patch it.  Patching is best prevented by making the whole file
immutable.

Bruce