From owner-freebsd-current Sun Oct 6 04:34:45 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA10240 for current-outgoing; Sun, 6 Oct 1996 04:34:45 -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 EAA10232 for ; Sun, 6 Oct 1996 04:34:39 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.7.6/8.6.9) id VAA25153; Sun, 6 Oct 1996 21:32:19 +1000 Date: Sun, 6 Oct 1996 21:32:19 +1000 From: Bruce Evans Message-Id: <199610061132.VAA25153@godzilla.zeta.org.au> To: bde@zeta.org.au, michaelh@cet.co.jp Subject: Re: secure level diffs to kern_mib.c, LINT Cc: current@freebsd.org Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >What changes would be necessary to *guarantee* that the system increments >securelevel to 1, *before* any deamons are started? Set the securelevel to 1 in the kernel or use sysctl to set it before starting any daemons :-), e.g. by booting with -s or setting it near the start of /etc/rc. Setting it to 0 in the kernel doesn't do this - then /etc/rc is run in single-user mode at securelevel 0, as it must to write to disks, and daemons are started at securelevel 0 and any disk writing permissions that they gain live across changes to securelevel. >I'm less concerned with putting securelevel=2 in rc, because this is just >locking another deadbolt and isn't as critical as the transition from 0 to >1. Actually, securelevel 1 is normally so insecure that it shouldn't be used. It essentially only provides write protection of /dev/mem and /dev/kmem. The write protection on mounted disks is worthless becauses there are lots of aliases. Even plain BSD has a whole disk partition, and FreeBSD has lots of slices and SCSI control devices. Perhaps this can be worked around by deleting the aliases. Bruce