[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: disk-destroyer.c
On Sun, 23 Jul 2000, Khimenko Victor wrote:
> If you are talking about FILE in /dev - you can create it with mknod.
> If you are talking about DEVICE in kernel - you are disabling it with
> CAP_SYS_RAW and it'll make access to IDE commands not possible as well
> with proposed trivial 2-lines patch (HDIO_DRIVE_CMD IS raw I/O after
> all so why it was not protected by CAP_SYS_RAW in first place in
> mystery to me).

That, surely, is simply a bug? In which case, the patch someone posted
earlier to change the two capable() checks should solve it fine, even if
the author isn't a voter with a T-1...

> JS> We cannot switch *ANYTHING* off for root while retaining raw hardware
> JS> access.
> Yes. And that's why we need such two-lines patch, not some AI in kernel.

We need the extra pair of capable() calls, yes. We should also have sanity
checking in the kernel: usermode shouldn't be given this sort of power
directly, it should go through a proper, sanity-checked API. Just look at
the flak MS took for not sanity-checking all the WIN32K.SYS functions...

> JS> I'd use another capability (SYS_DESTROY_HARDWARE) which isn't enabled for
> JS> anything by default. Apart from that, it's OK.
> Sorry. You misunderstood things. HDIO_DRIVE_CMD can be used for other things
> (like PIO change or putting drive in sleep; heck - even firmware upgrades
> can be usefull sometimes). So it SHOULD NOT be disabled by default. Yes, it's
> dangerous, but so are A LOT OF other usefull things.

Potentially dangerous hardware-dependent things should be done by/via the
driver for that hardware, NOT by handing userspace a nuke and pointing it
at the target!

> >> > I prefer the latter - leaving those things lying around is just *begging*
> >> > for the next Linux crack story to go "some bastard got in with an old buffer
> >> > overflow exploit, and toasted my $10k server just by running a shell script".
> >> > I don't want to see that one...
> >>
> >> I don't as well but we have choice.
> JS> We NEED to block this function somehow.
> We can not.

Why not? All the uses you mention should be done through a proper kernel
API - NOT by userspace things on a "trust me, I'm being run by root"

> JS> Nope - /dev/kmem is gone.
> How so ? You are not using XFree86, right ? Then you can remove CAP_SYS_RAW
> from system and be happy.

So it has gone. That's my point.

> JS> So long as not having CAP_DESTROY_HARDWARE prevents this, and
> JS> CAP_DESTROY_HARDWARE isn't available to anything by default, that's OK.
> Sorry. We CAN NOT do this. Have you EVER looked on proposed patch or you are
> just lurking here ?

The proposed patch was deleted from zeus shortly after upload, so I can't
look at it. I'm not interested in what that specific patch actually does -
it's the *design* that matters, and THAT is what is being discussed.

> If not then go and read it then go back. It tries to distinguish "bad
> commands" and "good commands". Good commands are allowed while bad
> ones do not.

Yep - Linux would be fscking broken otherwise.

> The problem with this approach is simple: there ARE "bad" commands
> which can be used legetimely (for firmware upgrade, for example -
> that's why they are there in first place :-)

No, this sort of direct access is not legitimate. It should be done
through a proper sanity-checked API. The "give userspace a nuke and pray"
approach belongs in Redmond-born OSs, not Linux.

> and even worse: what's "bad" command with one IDE HDD vendor can be
> "good" one (and wanted not only in rare cases where you want to
> upgrade firmware) one for other IDE HDD vendor

This is exactly the sort of hardware-dependent detail which the kernel
driver should handle, NOT leave up to userspace.

> (think about things like Western Digital's activeX app to do low-level
> disk diagnostics).

Oh, yes - very useful. I really want a piece of WWW page to be able to do
low-level things to my hardware. If you think that's a genuine feature, go
back to Redmond and resume patching QDOS derivatives.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.416 / U:1.840 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site