Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 6 Sep 1999 21:20:55 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Greg Black <gjb-freebsd@gba.oz.au>
Cc:        Dag-Erling Smorgrav <des@flood.ping.uio.no>, KATO Takenori <kato@ganko.eps.nagoya-u.ac.jp>, bde@zeta.org.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
Subject:   Re: Init(8) cannot decrease securelevel 
Message-ID:  <199909070420.VAA77483@apollo.backplane.com>
References:  <199909060513.PAA12402@godzilla.zeta.org.au> <19990906142342F.kato@gneiss.eps.nagoya-u.ac.jp> <xzp1zcco10z.fsf@flood.ping.uio.no>  <199909061539.IAA74893@apollo.backplane.com>  <19990906204930.14319.qmail@alice.gba.oz.au>

next in thread | previous in thread | raw e-mail | index | archive | help

:>     Though, as a side note, it should be noted that if you have DDB
:>     enabled then lowering the secure level is pretty easy to do.  If you
:>     have access to the console, of course.
:
:It should also be noted that it makes no sense to enable DDB on
:systems that need to use elevated securelevels.
:
:-- 
:Greg Black -- <gjb@acm.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.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



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?199909070420.VAA77483>