Messages in this thread | | | From | (John Alvord) | Subject | Re: The Full Explaination ... (re: disk-destroyer.c) | Date | Sat, 22 Jul 2000 16:50:40 GMT |
| |
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/
| |