The Full Explaination ... (re: disk-destroyer.c)

From: Andre Hedrick (andre@linux-ide.org)
Date: Fri Jul 21 2000 - 00:29:20 EST


On Thu, 20 Jul 2000, Myrddin Emrys wrote:

> On Thu, 20 Jul 2000 19:09:19 -0700 (PDT) you sent this message:
>
> >I try to provide a protective layer to the hardware and everybody says it
> >is not needed.
>
> Perhaps you were not explaining your position clearly. I gathered that the
> behavior, as described, was perfectly valid, just dangerous. You, on the
> other hand, are now clarifying that the behavior of the system, when those
> bytes were sent, is not correct. In other words, it's possible for the
> system to 'accidentally' fry a hard drive... is this correct?

Hi Myrddin,

You are correct I have not explained the magnitude, so here goes.
After I explain this, I will not take responsiblity of the destruction
that can happen. This burden will be passed to the Distributions and the
persons making final decisions of Kernel development. These will be the
people responsible for not taking the proper response to protect their
butts because I am now covering my butt legally, by a pro-active position.

I can not help 2.2 until I finish 2.4 with the last command fix.

Assume UID=0 and I do not care if it was hacked, a STUPID ROOT, or a SMART
ROOT......the issue is that something ROOT-LIKE has control.

**************************************************************************

I do not care if you are a stupid or smart root, HDIO_DRIVE_CMD should not
allow you to hurt the hardware, HDIO_DRIVE_TASK will do it better and
faster.

HDIO_DRIVE_TASK is the complete drive access command level.
HDIO_DRIVE_CMD is a subset.

HDIO_DRIVE_TASK can filter HDIO_DRIVE_CMD and deny invalid uses of its
power. Now HDIO_DRIVE_TASK would be a compile option to open this IOCTL.
Now regardless if the IOCTL is open or closed it will protect against
HDIO_DRIVE_CMD; however if HDIO_DRIVE_TASK is open then you have to know
the ATA specification to use it in a destructive mode. The hardware will
BUCK most of the time at improper use of HDIO_DRIVE_TASK, where unfiltered
HDIO_DRIVE_CMD the kernel will assist you in the destruction.

For those that think I am taking away your ROOT powers, I am giving you
MORE and better ways to screw yourself, should you by your own accord want
to enable an option to allow this feature. Now you are responsible for
your actions again.

All I want is to protect JOE SIX-PACK new user that is not security savy
from losing his hardware with the kernel assisting in the destruction.
Is this to much to ask?

The rest of the power if the TASK interface is incomplete for user-space.
However this is enough to protect against BAD HDIO_DRIVE_CMD calls.

**************************************************************************

Respectfully,

Andre Hedrick
The Linux ATA/IDE guy

-
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:14 EST