Messages in this thread | | | Date | Sat, 22 Jul 2000 01:34:34 +0300 | From | Ville Herva <> | Subject | Direct access to hardware |
| |
On Fri, Jul 21, 2000 at 11:02:58PM +0400, you [Khimenko Victor] claimed: > In <Pine.LNX.4.21.0007212009040.5384-100000@tricky> Bartlomiej Zolnierkiewicz (dake@staszic.waw.pl) wrote: > > > BTW: software may (but don't have to) damage BIOSes, firmwares, CPUs > > (programming PLL on mobo), older monitors, ISA/PCI cards (programming > > southbridge to get ISA/11Mhz and PCI/41.5Mhz)... etc... > > just imagine advanced worm (similar to the one discribed in some > > lcamtuf's project) making use of all hardware "features"... ugh... > > > The ONE and ONLY solution is r00t without direct access to hardware... > > Yeah. Hmm. Looks like I can userstood now: if direct access to hardware > (and to /dev/kmem, of course) is disabled (some router or firewall so > capabilities are removed from system) but you STILL need HDIO_DRIVE_CMD > then yes, in this RARE scenario this patch is usefull. Huh. Someone knows > at least ONE system in such configuration and with such need ?
So, would it be feasible to make it possible to disable direct hardware access (/dev/mem, /dev/nvram, HD ioctls, what else?) completely in kernel config? Or are some of those always needed? If not, then they could be disabled (do not enable what you don't need, as with /etc/inetd) on a trivial web server box, route, firewall etc. Of course, kernel module loading should be disabled as well (or made available only via challange-response authentication or something (*)). Make your boot media read-only, and the cracker shouldn't be able to change the kernel either.
Which applications need (dangerous) direct hardware access? In which cases would it be possible to disable it? You can't propably shield your monitor if you want to run X, but for server boxes, that's not a big deal.
If nothing else, people running honey pot boxes to attract crackers would propably want to use this.
Or is this a completely dead idea?
-- v --
v@iki.fi
(*) Publib key in kernel, private key held separately by the administrator. Without writable /dev/mem (etc) this should work?
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |