Skip site navigation (1)Skip section navigation (2)
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>