Date: Mon, 10 Jun 1996 12:22:45 +1000 From: Bruce Evans <bde@zeta.org.au> To: taob@io.org, wollman@lcs.mit.edu Cc: freebsd-security@FreeBSD.ORG Subject: Re: Effects of kern.securelevel >= 0 Message-ID: <199606100222.MAA25496@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199606100222.MAA25496>