Date: Mon, 6 Sep 1999 13:29:44 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Matthew D. Fuller" <fullermd@futuresouth.com> 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: <199909062029.NAA76229@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> <19990906141231.L18814@futuresouth.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Mon, Sep 06, 1999 at 08:39:54AM -0700, a little birdie told me
:that Matthew Dillon remarked
:>
:> 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. We used this trick at BEST
:> a couple of times. Still, I think this might qualify as a bug in
:> the securelevel implementation.
:
:I don't know about 'bug in securelevel implementation'...
:For DDB to be DDB, you have to be able to tweak the running kernel any
:which way outside of its control. For securelevel to be securelevel, you
:have to prevent changes to X, Y, and Z, no matter how they're changed.
:
:I think it's more of a 'DDB is antithecal to securelevel'. Calling it a
:bug in securelevel is like calling lack of cargo space a bug in a Geo
:Metro.
:
:Matthew Fuller (MF4839) | fullermd@over-yonder.net
Well, if you are using DDB for kernel debugging via remote gdb,
that is so.
In the production installation at BEST we leave DDB turned on
in order to be able to track panics and control dumps. We do
not use it for remote gdb debugging.
I think the vast majority of production installations which use
DDB only need the trace, show, and panic capability. They
probably do not need to issue writes into kernel memory. In
these installations DDB is necessary to deal with system panics,
so turning it off is not really an option.
So making DDB 'secure-level friendly' would be a useful thing
tgo do, I think. The idea is not to disable DDB, but to simply
limit the actions that can be performed within it if the securelevel
has been raised. The sysadmin would only be allowed to issue
passive commands, cont, and 'panic'. The sysadmin would not be
allowed to modify the running system.
A hacker in a similar situation would not be able to do anything
beyond crash the machine. I would rather a machine crash then
give a hacker the ability to defeat the security mechanism in
order to gain access to the system and modify data.
-Matt
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?199909062029.NAA76229>