mailing list archives
From: codewarrior () daemon org (Andrew Brown)
Date: Sat, 30 Aug 1997 14:16:54 -0400
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.
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.
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."