Linux-kernel mailing list archive 2000-29,: Re: disk-destroyer.c

# Re: disk-destroyer.c

James Sutherland (jas88@cam.ac.uk)
Fri, 21 Jul 2000 21:38:41 +0100 (BST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Bartlomiej Zolnierkiewicz: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Previous message: Keith Owens: "Re: Cache coherency... and locking"

On Fri, 21 Jul 2000, Dan Hollis wrote:

> On Fri, 21 Jul 2000, James Sutherland wrote:
> > On Thu, 20 Jul 2000, Dan Hollis wrote:
> > > Ok, you prevent program from sending DISKTOBRICK IOCTL as root...
> > > So disk2brick.c will just bypass the kernel API and bit-bang on the IDE
> > > controller directly...
> > If a usermode app can hit the hardware directly like that, there's
> > something VERY broken...
>
> James, you can erase BIOS flash from linux userland,

Urgh. That should be fixed at some point too, then. Everything userland
does with hardware should go via the kernel, and it should be possible for
the kernel to block/restrict that access.

> you could probably even physically destroy it too. I can think of
> great ways of physically destroying one's CPU and maybe even
> motherboard too, from userland.
>
> This is nothing new.
>
> Is the kernel broken because you can bit-bang the hardware as root?

Yes. See later.

> Think about it.

Think about this: there are situations where root *MUST* be subject to
various restrictions (via capabilities, immutable files, etc). If root is
able to talk directly to the hardware, these restrictions become
unenforcable - security just went out of the window. This is unacceptable:
Linux must not do it. (Or rather, it must be possible to prevent Linux
doing it.)

James.

-
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/

- Next message: Bartlomiej Zolnierkiewicz: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Previous message: Keith Owens: "Re: Cache coherency... and locking"