DDB is the kernel debugger. It lets you debug the kernel upon a panic or when you wish to enter it via a key sequence on the console. There appears to be a slight problem though, you can use DDB to lower the securelevel of the system. The following shows one example: # sysctl -w kern.securelevel=10 kern.securelevel: 0 -> 10 # Debugger("manual escape to debugger") Stopped at _Debugger+0x35: movb $0,_in_Debugger.118 db> write securelevel 0 _securelevel 0xa = 0 db> cont # sysctl kern.securelevel kern.securelevel: 0 # 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. *** i386/i386/db_interface.c Sat Aug 30 08:57:36 1997 --- i386/i386/db_interface.c.new Sat Aug 30 09:00:43 1997 *************** *** 241,246 **** --- 241,256 ---- /* * XXX + * Do nothing if the securelevel is > 0. The justification + * being that DDB can be used to lower the securelevel, so + * if we run > 0, we should not be able to run DDB at all. + * Modifying DDB to be securelevel friendly is not an option. + */ + if(securelevel > 0) + return; + + /* + * XXX * Do nothing if the console is in graphics mode. This is * OK if the call is for the debugger hotkey but not if the call * is a weak form of panicing. ---------------------------------------------------------------------------------- >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.