[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.026 / U:4.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site