Bugtraq mailing list archives
Re: DDB/securelevel
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.
<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."
Current thread:
- Re: syslogd fun (erratum) Yuri Volobuev (Aug 28)
- Having fun with eggdrop bot Giuliano COCAINE (Aug 28)
- Re: Having fun with eggdrop bot The Nolander (Aug 29)
- Re: Having fun with eggdrop bot -*- Chotaire -*- (Aug 29)
- DDB/securelevel Aleph One (Aug 30)
- Re: DDB/securelevel Andrew Brown (Aug 30)
- Mac TCP/IP Stack glitch. nomad () APOLLO TOMCO NET (Aug 31)
- Re: Having fun with eggdrop bot The Nolander (Aug 29)
- Having fun with eggdrop bot Giuliano COCAINE (Aug 28)
- Re: syslogd fun (erratum) Theo de Raadt (Aug 28)
- SGI security patches Martin J. Dellwo (Aug 29)
- Somewhat of a security hole in CVS Elliot Lee (Aug 29)
- Re: Somewhat of a security hole in CVS Theo de Raadt (Aug 29)
- Re: Somewhat of a security hole in CVS Marc Slemko (Aug 29)
- rpm 2.4.6 (with /tmp fixes) Erik Troan (Aug 29)