From owner-freebsd-hackers Mon Sep 6 23:17:56 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from mrelay.jrc.it (mrelay.jrc.it [139.191.1.65]) by hub.freebsd.org (Postfix) with ESMTP id B4F0515772; Mon, 6 Sep 1999 23:17:51 -0700 (PDT) (envelope-from nick.hibma@jrc.it) Received: from elect8 (elect8.jrc.it [139.191.71.152]) by mrelay.jrc.it (LMC5692) with ESMTP id IAA07918; Tue, 7 Sep 1999 08:13:34 +0200 (MET DST) Date: Tue, 7 Sep 1999 08:13:35 +0200 (MET DST) From: Nick Hibma X-Sender: n_hibma@elect8 Reply-To: Nick Hibma To: Matthew Dillon Cc: Greg Black , Dag-Erling Smorgrav , KATO Takenori , bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Init(8) cannot decrease securelevel In-Reply-To: <199909070420.VAA77483@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > I disagree quite strongly. DDB provides a mechanism to allow a > sysadmin to obtain a greater amount of information from a panic > situation then he could get otherwise. Being able to obtain this > information does not run counter to running with a raised securelevel. > > If the system winds up in a state where a kernel core cannot be > generated, DDB is the only way to figure out what is going on. > securelevel is a mechanism which attempts to guarentee data security, > at least to a degree. These two items do not clash. > Anyway, as soon as you can physically access the PC, youD loose anyway, independent of whether you can go into DDB to do things. You can reboot, boot a floppy. Yes you can do something about those things, but only to a limited extent. Nick -- ISIS/STA, T.P.270, Joint Research Centre, 21020 Ispra, Italy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message