Re: disk-destroyer.c

From: James Sutherland (jas88@cam.ac.uk)
Date: Sat Jul 22 2000 - 16:48:58 EST


On Sat, 22 Jul 2000, Khimenko Victor wrote:
>
> > Urgh. That should be fixed at some point too, then.
>
> Yes. What's MORE amusing that it WAS fixed. For years I had this small jumper
> on my MB to disable writes to flash BIOS.

A nice feature - so WTF did it go on newer mobos? Are jumpers REALLY that
expensive? ;-)

> > Everything userland does with hardware should go via the kernel, and it
> > should be possible for the kernel to block/restrict that access.
>
> Great idea. Perhaps 10 years later we'll have such system. For now we have
> no choices: some work with video cards NEED access to hardware (acceleration;
> and you DO NOT want acceleration to go via the kernel, really).

IOW, ONE particular driver SOMETIMES needs to do this. Why can't it be
done via the kernel? Everything else is fine this way...

> >> 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.)
>
> It IS possible. Remove CAP_SYS_ADMIN and CAP_SYS_RAW capabilities from
> system. Yes, perhaps patch to require CAP_SYS_RAW for RAW ide commands
> can go in. It's quite different thing then proposed papering over hole.

It's almost exactly the same. One approach blocks the harmful command
unconditionally, the other makes it condition on a special setting. Hardly
worth starting YALKFW (Yet Another L-K Flame War) over, surely, especially
since there aren't any valid uses for this command yet...

IMO, Andre's patch should go in, maybe leaving a "backdoor" for later in
case we need it. I'd prefer to keep HDD firmware updates on the same level
as CPU microcode updates, NVRAM access etc (i.e. going via a kernel
driver properly), though.

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/



This archive was generated by hypermail 2b29 : Sun Jul 23 2000 - 21:00:19 EST