Date: Fri, 18 Jun 1999 01:35:49 -0500 (CDT) From: Frank Tobin <ftobin@bigfoot.com> Cc: freebsd-security@freebsd.org Subject: Re: securelevel descr Message-ID: <Pine.BSF.4.10.9906180119201.50701-100000@srh0710.urh.uiuc.edu> In-Reply-To: <Pine.LNX.4.05.9906180220350.16657-100000@jason.argos.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike Nowlin, at 02:21 on Fri, 18 Jun 1999, wrote: > What are the various secure levels, and what does each one do? Read man init(8). Nice descriptions. I was talking over something with friends today, and we were trying to come with ideas for securelevels that would disable as much meaning out of being root, to limit the spread of being root if a box is 'rooted'. Specifically, we came to the conclusions that with most of /etc, /usr (with the notable exceptions of /etc/passwd, catman, /usr/local) could be chflagged simmutable, and a securelevel of 3 could really strengthen a box. Of course, one additional thing that no secure level does that would be _really_ nice is that it would prevent more secure ports from being opened. This would be extremely advantageous, as it would eliminate _any_ possibility of a trojan daemon being opened on a secure port for devious means, such as password-gathering. Since the daemon itself would be simmutable, and would open its ports before the securelevel is raised, there would be no way to trojan the process, since it can't be replaced, and can't be killed/restarted, and its memory can't be written to. Of course, putting such a thing into the securelevels would create a need for the network daemons to start up in a different order, sooner. For example, sshd couldn't be in /usr/local/etc/rc.d, but started up before the raised securelevel. Or this could actually instead be done with a securelevel of 4 (no secure ports opened), which is raised to after all startup scripts have ended. This would be preferable because it could start the sshd under a securelevel of 3, protecting the filesystem from a buggy sshd. Of course, your daemon better not die in this scenario, or you have to be running inetd. Your inetdn't should really be dying though :) I feel this addition to the securelevels would be a GREAT enhancement to the ability of an administrator to 'lock down' a box. I really do wish I had the expertise to implement it. I would be most appreciative if I saw this change added to FreeBSD. -- Frank Tobin "To learn what is good and what is to be http://www.bigfoot.com/~ftobin valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus FreeBSD: The Power To Serve PGPenvelope = GPG and PGP5 + Pine PGP: 4F86 3BBB A816 6F0A 340F http://www.bigfoot.com/~ftobin/resources.html 6003 56FF D10A 260C 4FA3 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9906180119201.50701-100000>