[lkml]   [2000]   [Jul]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Direct access to hardware
    In <> Ville Herva ( wrote:
    > On Fri, Jul 21, 2000 at 11:02:58PM +0400, you [Khimenko Victor] claimed:
    >> In <Pine.LNX.4.21.0007212009040.5384-100000@tricky> Bartlomiej Zolnierkiewicz ( wrote:
    >> > BTW: software may (but don't have to) damage BIOSes, firmwares, CPUs
    >> > (programming PLL on mobo), older monitors, ISA/PCI cards (programming
    >> > southbridge to get ISA/11Mhz and PCI/41.5Mhz)... etc...
    >> > just imagine advanced worm (similar to the one discribed in some
    >> > lcamtuf's project) making use of all hardware "features"... ugh...
    >> > The ONE and ONLY solution is r00t without direct access to hardware...
    >> Yeah. Hmm. Looks like I can userstood now: if direct access to hardware
    >> (and to /dev/kmem, of course) is disabled (some router or firewall so
    >> capabilities are removed from system) but you STILL need HDIO_DRIVE_CMD
    >> then yes, in this RARE scenario this patch is usefull. Huh. Someone knows
    >> at least ONE system in such configuration and with such need ?

    > So, would it be feasible to make it possible to disable direct hardware
    > access (/dev/mem, /dev/nvram, HD ioctls, what else?) completely in kernel
    > config?

    Grrr. It's doable from userspace. Just echo appropriate number in
    /proc/sys/kernel/cap-bound in /sbin/init (or early in rc.S) and that's all.

    > Or are some of those always needed? If not, then they could be
    > disabled (do not enable what you don't need, as with /etc/inetd) on a
    > trivial web server box, route, firewall etc.

    You CAN disable it all with one small keystroke.

    > Of course, kernel module loading should be disabled as well (or made
    > available only via challange-response authentication or something (*)).

    You can load all needed modules and then disable modules loading with the
    same /proc/sys/kernel/cap-bound ...

    > Make your boot media read-only, and the cracker shouldn't be able to
    > change the kernel either.

    > Which applications need (dangerous) direct hardware access?


    > In which cases would it be possible to disable it?

    When you do not need GUI :-)

    > You can't propably shield your monitor if you want to run X, but for server
    > boxes, that's not a big deal.

    Exacttly. And for such protection you DO NOT NEED Andre's patch. You need
    MUCH smaller and clearer Vojtech's patch (just two lines instead of 60K).

    > If nothing else, people running honey pot boxes to attract crackers would
    > propably want to use this.

    > Or is this a completely dead idea?

    It's not dead idea. Even more: such protection ALREADY is offered by kernel.

    > (*) Publib key in kernel, private key held separately by the
    > administrator. Without writable /dev/mem (etc) this should work?

    No, this is not implemented (yet?). You can load all needed modules early in
    boot process and then disable everything non-needed (including ability to
    load modules).

    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.047 / U:25.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site