Linux-kernel mailing list archive 2000-29,: Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)

# Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)

Khimenko Victor (khim@sch57.msk.ru)
Sat, 22 Jul 2000 17:21:27 +0400 (MSD)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Khimenko Victor: "Re: disk-destroyer.c"
- Previous message: Alan Cox: "Re: IF only........g"
- Maybe in reply to: Andre Hedrick: "TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Next in thread: Henning P. Schmiedehausen: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"

In <Pine.LNX.4.21.0007210430330.21877-100000@bodnar42.dhs.org> bodnar42@bodnar42.dhs.org (bodnar42@bodnar42.dhs.org) wrote:
> On Fri, 21 Jul 2000, Peter Svensson wrote:

>> On Fri, 21 Jul 2000 bodnar42@bodnar42.dhs.org wrote:
>>
>> Most people are not arguing that the patch is useless. It isn't, it
>> prevents accidental destruction of a disk. If it is worth the space in the
>> kernel for that added layer of protection against brogen programs is for
>> the kerlen gods to decide.

> The question becomes: if an invaild IDE command is sent from userspace,
> are the programs broken, or is the kernel? In this case, I think there
> kernel is broken.

If it's possible without CAP_SYS_RAW, then yes, it's kernel's fault AND SHOULD
BE FIXED (it's possible now without CAP_SYS_RAW AFAIK). If it's possible with
CAP_SYS_RAW it's program's fault. So Andre was correct: fix is needed
(since AFAIK currently you CAN do this without CAP_SYS_RAW) but it was not
correct as well: his "fix" was just to add bunch of checks instead of few
(or one?) "capable(CAP_SYS_RAW)" checks.

> It provides a method of communicating with ATA disks using the ATA
> specification.

ONLY if you have no CAP_SYS_RAW. If you have you CAN do whatever you want with
hardware.

> However, if you give it the wrong input, it will violate that specification.

No problem: with CAP_SYS_RAW you can do it anyway.

> This behavior is wrong, and although the invalid request originated in
> userspace, it is the kernels job to identify it as invalid and refuse to
> send the command.

See above.

> To carry on the networking metaphor, imagine writing an app that tries to
> write() on a unconnected socket, and when you ran it as root it
> would cause your kernel to panick. Fixing this would not be considered an
> "added layer of protection against broken apps", it would be considered a
> bug fix. This is only different in that the interface is used less often,
> and misuse can cause more damage.

You networking example is GREAT. You even not realising just HOW GOOD it is.
Let's take one more look on it: we have broken kernel (it'll panic when you'll
do nasty things with sockets - for example linux kernel 2.2.15) and broken
program (it's trying to do such nasty things - any version of PostgreSQL).
And now you are proposing to add fix in middleware (in GLibC). What you'll
get as responce ? "Are you idiot, or what ? It's kernel's fault, not GLibC's
fault! Go and fix it in kernel instead!". And that's exactly what was done
(fix is in 2.2.16 and recent 2.4.0-testX kernels). BTW: it's not hypotetic
example but that's what REALLY happened: I found that PostgreSQL can provocate
kernel panic by abusing sockets and then this problem was fixed. In kernel
(that is: where it was introduced in first place), not in GLibC. In our case
we can not even TRY to fix broken hardware (if user have raw access to hardware
that is; if user DOES not have raw access to hardware then indeed he should not
be allowed to damage even broken hardware): it's task for hardware manufaturers,
not for linux developers.

> Andre, do you have any idea how much space this will take up in the
> kernel? I have no idea how advanced the heuristics will have to be...

It should be few lines to check if user have CAP_SYS_RAW for potentially
dangerous commands. That's all. Nothing more, nothing less. NO heuristics.

>> What it does not do is provide protection against malicious destruction of
>> a disk. To destroy the disk you need root before the patch and root after
>> the patch and that is it. The recent proliferation of rather complex
>> exploits of holes in programs shows that even problems that are hard to
>> exploit will be exploited. Using direct io to destroy the
>> bios/disk/whatnot with direct io is not beyond their reach I suspect.

> Yes, I totally agree

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

- Next message: Khimenko Victor: "Re: disk-destroyer.c"
- Previous message: Alan Cox: "Re: IF only........g"
- Maybe in reply to: Andre Hedrick: "TO HELL WITH IT THEN......(re: disk-destroyer.c)"
- Next in thread: Henning P. Schmiedehausen: "Re: TO HELL WITH IT THEN......(re: disk-destroyer.c)"