Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 Aug 1997 11:47:25 -0700
From:      Cy Schubert <cy@uumail.gov.bc.ca>
To:        Andrew Brown <codewarrior@daemon.org>
Cc:        BUGTRAQ@netspace.org, freebsd-security@freebsd.org
Subject:   Re: DDB/securelevel 
Message-ID:  <199708311847.LAA03326@cwsys.cwent.com>
In-Reply-To: Your message of "Sat, 30 Aug 1997 14:16:54 EDT." <199708301816.OAA09934@untraceable.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
There's a lot to be said about physical security.  If one has a sensitive
application, physically secure the machine.

Secondly, DDB should not be compiled into the kernel of a production
machine unless you are trying to resolve a software or hardware problem.
Once a problem is resolved, remove the option from the kernel config, not
only for security reason but to generally improve performance.  I, for
example don't include the KTRACE or bpfilter options for a production
machine unless I am trying to solve a problem.  Most security publications
and auditors agree that removing bpfilter can improve network security. 
Removing these options on a production machine can also improve performance
because the kernel is not executing rarely used code


Regards,                       Phone:  (250)387-8437
Cy Schubert                      Fax:  (250)387-5766
UNIX Support                   OV/VM:  BCSC02(CSCHUBER)
ITSD                          BITNET:  CSCHUBER@BCSC02.BITNET
Government of BC            Internet:  cschuber@uumail.gov.bc.ca
                                       cschuber@bcsc02.gov.bc.ca

		"Quit spooling around, JES do it."

> >The most straightforward solution to this is to simply not allow
> >DDB to be run when securelevel > 0. Enclosed is a simple patch
> >against 2.2.1 to do this.
> 
> <rant>
> this is just about the dumbest thing i've ever heard.  while i
> realize that freebsd usually runs in securelevel -1, most other bsd's
> run at 0 or 1 (or even 2 for the paranoid).  when would you *ever*
> build a kernel with ddb where console security was even close to being
> an issue.  not being able to run ddb defeats the purpose of building
> ddb into the kernel in the first place.  what if you were trying to
> debug code that only got called when the machine was at a high
> securelevel and it caused the machine to panic?  you wouldn't be able
> to fix it very easily.
> 
> first of all, ddb can be used for a lot more things than just lowering
> the securelevel.  you can a) raise your privelege level (walk the
> process list, find the cred stuff for the appropriate process, and
> change it :), b) make the machine panic c) remove the code that
> prevents you from doing any number of things while at a higher
> securelevel, d) remove the code that prevents you from removing the
> code that prevents you from doing things at a higher securelevel, etc.
> 
> i first thought about this when the problem with the init image under
> the proc filesystem was pointed out.  then i patched ddb so that you
> could not write to the securelevel, naively thinking that would take
> care of it.  about ten minutes later i had eliminated the code that
> checked to see if you were writing the securelevel and had changed the
> securelevel back.  then i briefly considered having ddb keep a map of
> what pages it can modify and what pages it can't (including in the
> map, the pages that contained the map and the pages that contained the
> code that checked the map.  i decided against this, since it would
> probably cause more problems than it fixed.
> 
> it doesn't stop there.  when i was working in the computer lab at
> college, the gateway computers there had nice, fancy programmable
> keyboards.  i had occasion to watch somebody log in, crash the
> machine, reboot and *watch the keyboard log him back in*.  assume that
> you don't even need console access to this computer, you can still
> probably program the keyboard to drop into ddb, lower the securelevel
> for you, and continue.
> 
> basically, what it comes down to is that running with ddb in your
> kernel is equivalent to running with the securelevel set to "fly
> unzipped".  not that ddb isn't a good, thing, you just need to be
> aware of it.
> </rant>
> 
> thanks for listening...  :)
> 
> --
> |-----< "CODE WARRIOR" >-----|
> andrew@echonyc.com (TheMan)        * "ah!  i see you have the internet
> codewarrior@daemon.org                               that goes *ping*!"
> warfare@graffiti.com      * "information is power -- share the wealth."
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199708311847.LAA03326>