lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: The Full Explaination ... (re: disk-destroyer.c)
Date
On Fri, 21 Jul 2000 12:02:34 -0500, Myrddin Emrys <myrddin@iosys.net>
wrote:

>On Thu, 20 Jul 2000 22:29:20 -0700 (PDT) you sent this message:
>
>>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.
> <snip>
>>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?
>
>Hmm. I guess that your and my definition of 'Joe Six-Pack' is different. In
>my world, Joe Six-Pack won't be compiling and running disk2brick.c on a
>Linux box. Joe Six-ack has difficulty even leaving X without hand holding.
>
>But that is a moot point. I think, idealistically, your position is correct.
>What I think you are incorrect about is the urgency with which you advocate
>your position. The fix is not urgent, it's minor. There are ways of frying
>hardware in userspace, a real where Joe Six-Pack is FAR more likely to be...
>protection in the kernel against one specific hack adds little security.
>
>As someone else pointed out, now is not the time to be adding changes like
>this (just before a stable release). Offer the patch after the next stable
>kernel, when less urgent changes are easier to get in. Remember that you're
>not patching a gaping hole... you're blocking one of a hundred ways that
>root can fry hardware. There are many other ways still to go, so having 99
>ways to fry the system, instead of 100, is not that big of a fix. Eventually
>we may get down to 0, but until we get close to that ideal, each cemented
>hole is a minor change not urgent enough to risk destabilizing an even
>release.

In any case, the real exposure is all the 2.0 and 2.2 installed
systems, which probably compose 99% of all Linux systems in
production. Otherwise a few hundred developer and early tester systems
are covered and nobody else. Think of all those boxes of RedHat
distributions sitting in Walmart and Costco and OfficeMax stores...

John Alvord

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

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