lkml.org 
[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: disk-destroyer.c
    In <Pine.LNX.4.10.10007222320140.5862-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
    JS> On Sat, 22 Jul 2000, Khimenko Victor wrote:

    >> In <Pine.LNX.4.10.10007221209030.5294-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
    >> > On 21 Jul 2000, Henning P. Schmiedehausen wrote:
    >>
    >> >> jas88@cam.ac.uk (James Sutherland) writes:
    >> >>
    >> >> >> So disk2brick.c will just bypass the kernel API and bit-bang on the IDE
    >> >> >> controller directly...
    >> >>
    >> >> >If a usermode app can hit the hardware directly like that, there's
    >> >> >something VERY broken...
    >> >>
    >> >> If it can not, I'll simply whip up a kernel module which I can acess
    >> >> from user space, which can.
    >>
    >> > There's a hell of a big difference between "type this code into
    >> > EDITOROFCHOICE, compile and run and your drive is a paperweight" and
    >> > "rebuilt the kernel, deleting this bit and inserting this replacement
    >> > driver, then proceed as above".
    >>
    >> Not exactly. You can as easily remove all Andre's checks via /dev/kmem.
    >> Program will be slightly bigger but not much.

    JS> /dev/kmem disappears along with all the other bypass routes on a
    JS> thoroughly secured system.

    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).

    >> >> What I tried to understand in between Andre's swearwords, is that you
    >> >> can enable drives to access a full set of parameters ("taskfile") or
    >> >> you can disable this. If you enable it, you can fry the drive. If you
    >> >> disable it, you can't but you can still use the regular ATA command
    >> >> set which is all that the kernel will ever need.
    >>
    >> > Yep. There's a big red self-destruct button on the drive. Either we leave
    >> > it enabled, or switch it off.
    >>
    >> 1. We can not switch it off while retaining raw hardware access.

    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.

    >> 2. We can make it inaccessible for someone without CAP_SYS_RAW by two lines
    >> patch instead of 60K patch.

    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.

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

    >> >> The question now is: Once you disabled this, you can't enable it
    >> >> again? If this is truw, then I can understand many of the strange
    >> >> words that Andre used (though I still think that he was/is under deep
    >> >> sleep deprivation and strong drugs). If you can reenable this access,
    >> >> then there is no point.
    >>
    >> > Once blocked by the kernel, you have to do strange and nasty things
    >> > (screwing with the kernel, then rebooting with your own version,
    >>
    >> Huh ? You just need to grep over /dev/kmem and replace few bytes there.
    >> Not such a big deal.

    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.

    >> > or using Linux's biggest security flaw to bypass everything) to get this
    >> > `feature' available again.
    >>
    >> See above.

    JS> As above, it's gone.

    >> > At a later date, I want to see that flaw closed too, but it's harder.
    >>
    >> It's IMPOSSIBLE as long as "root is god". And if root was retired from gods
    >> via /proc/sys/kernel/cap-bound it's impossible at all and you do not need
    >> this patch for that.

    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 ? 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. 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 :-) 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 (think about things like Western Digital's activeX app to
    do low-level disk diagnostics).




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

    \
     
     \ /
      Last update: 2005-03-22 13:57    [W:4.260 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site