OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
FreeBSD Security Archives: Re: Init(8) cannot decrease securele

Re: Init(8) cannot decrease securelevel

Matthew Dillon (dillonapollo.backplane.com)
Mon, 6 Sep 1999 13:29:44 -0700 (PDT)

: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) | fullermdover-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 majordomoFreeBSD.org
with "unsubscribe freebsd-security" in the body of the message

This archive was generated by hypermail 2.0b3 on Mon Sep 06 1999 - 15:32:36 CDT