Re: Does this help explain better?? ATA/IDE Thread

From: Kurt Garloff (garloff@suse.de)
Date: Tue Jul 25 2000 - 08:20:20 EST


On Sat, Jul 22, 2000 at 02:50:39AM -0400, Stephen Frost wrote:
> I say it sounds like a hack because it disables a valid part of
> the SPEC because of concern that it could possibly be used
> incorrectly/improperly. One suggestion that I've heard so far is that
> CAPs be used and having things by default give up those CAPs on boot. I
> suspect anyone as root could re-aquire the CAPs, but then, they could do
> the same thing in other ways once they have root anyway.

That's the reason, why this whole discussion was considered void by a lot of
people: You need to be root in the first place in order to destroy the
harddisk. (And Andre always pointed to root exploits, when being told this.)

The point about CAPs is that you may rather easily load a module which can't
be unloaded and which would prevent to regain CAP_RAWIO ...
You could still come up with another module to hack this, but you may as
well disable module loading. Such things exist (secumod), but they are
seldomly used, as you also shut down a lot of functionality.

> This would
> prevent accidental destruction via this method though (I believe). Of
> course, you could accidentally perform the same operation in other ways
> as well given the moon is in the right phase.

No, the destruction NEVER comes accidently. Or, say, with a probability of a
computer tunneling out of the window without destroying the glass.

> Now, if a drive can be written to in such a way that this
> information is corrupted, one would *tend* to think that if the *correct*
> information is written back to that same area you might be able to
> recover the disk. I have no clue as to if this is actually the case or
> not or if there is a way this could be done, but it seemed like a
> reasonable question to bring up: Can a drive be fixed as it was broken?

Depends on the design of the firmware. Some firmware consist of two parts. A
unerasable part, which is mainly able to accept and checksum uploaded
firmware and the upgradeable firmware used for the normal operation. If you
happen to have such a design, you are lucky; just download the correct
firmware, if you get hold of it.
I'm afraid most firmwares will not be designed that way and also allow you
to erase the part which is needed to get newer firmware in the drive. Or
screw up communication so badly that the download will not work any more.
So, no remedy by software only!

Regards,

-- 
Kurt Garloff  <garloff@suse.de>                          Eindhoven, NL
GPG key: See mail header, key servers         Linux kernel development
SuSE GmbH, Nuernberg, FRG                               SCSI, Security


- 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 : Mon Jul 31 2000 - 21:00:19 EST