From owner-freebsd-security Sun Jun 9 19:27:26 1996 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id TAA18463 for security-outgoing; Sun, 9 Jun 1996 19:27:26 -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 TAA18404 for ; Sun, 9 Jun 1996 19:27:14 -0700 (PDT) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id MAA25496; Mon, 10 Jun 1996 12:22:45 +1000 Date: Mon, 10 Jun 1996 12:22:45 +1000 From: Bruce Evans Message-Id: <199606100222.MAA25496@godzilla.zeta.org.au> To: 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. 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 cvs history is a bit complicated. The variable used to be in kern_sysctl.c, and still is in -stable. init.c expects the 4.4Lite setting but this was changed long ago: RCS file: /home/ncvs/src/sys/kern/kern_sysctl.c,v ---------------------------- revision 1.6 date: 1994/08/10 02:41:09; author: wollman; state: Exp; lines: +2 -2 Change default security level to -1, so that users don't get bitten by upcoming makefile change. ---------------------------- >> Also, are there any caveats to running an ISP shell login server >> with securelevel 2? I recall that an old version of XFree86 would >> complain at level 1+ because it seemed to want to write to /dev/mem >> (VGA memory access?). I can't think of any side effects (no user >> should be fiddling with raw disk devices anyway). >Unfortunately, there are still a number of other holes, like /dev/io, >that would need to be closed before this was a truly ``safe'' >environment. /dev/vga provides the same hole as /dev/io. X and securelevel >= 1 are currently incompatible (X wouldn't work if the holes were closed). >> My main concern was the ability to turn off schg/sappnd flags at >> level -1 or 0. I suppose, however, that if someone was able to >> execute commands as root, that person could just add commands to >> /etc/rc to do their dirty deeds and reboot the machine... :( >That's why, when setting up a secure system, you have to make /etc/rc, >and all the files it depends on, immutable, and all the important >system directories append-only. Including all the directories above the system directories. You should also normally disable booting (in immutable hardware) and only boot from read-only media and check all the important files and directories before using them. Bruce