[lkml]   [2000]   [Jul]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectDirect 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 ( 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 --

(*) 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.233 / U:5.444 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site