OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Crist J. Clark (cristjcearthlink.net)
Date: Thu Oct 04 2001 - 04:30:34 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    On Sat, Sep 08, 2001 at 10:53:08AM -0500, D J Hawkey Jr wrote:
    > On Sep 08, at 06:37 PM, Peter Pentchev wrote:
    > >
    > > > Q: Can the kernel be "forced" to load a module from within itself? That
    > > > is, does a cracker need to be in userland?
    > >
    > > Yes, certainly; all kldload(8) does is invoke the kldload(2) syscall,
    > > nothing more, nothing userspace-magical.
    > > All a kernel routine needs to do is either invoke that syscall, or
    > > call the internal kernel functions that kldload(2) calls, like e.g.
    > > linker_find_file_by_name() and linker_load_file() in sys/kern/kern_linker.c
    >
    > Ah. Well then, as I wrote to Kris, the kernel has to deny KLD loading
    > altogether, it should be a build-time option, and it should have nothing
    > to over-ride this.
    >
    > Or am I still being too simplistic? I haven't been using KLD- or LKM-
    > aware systems very long (~one year), but so far I've had little use for
    > them (the modules). I get a box, I configure the kernel to it, and that's
    > that. If the box changes, I build a new kernel. At least for the servers
    > I've set up, this works fine. Now, a development or users' box, well...

    Yes, I am still catching up on email almost a month old.

    I went in and made a very simple kernel-build option which disables
    the use of kldload(2) (and kldunload(2)) at all times. This is not as
    good as raising securelevel(8) since root can still write to
    /dev/mem. However, a lot of people in this thread still seem to want
    this ability. Since you can still write to /dev/mem, it is only raises
    the bar a bit for an attacker. But it does raise the bar enough to
    possibly foil a skr1pt k1ddi3 or two.

    To use the patches,

      # cd /usr/src
      # patch < /path/to/sys_patch

    Add the line,

      options NO_KLD

    To your kernel configuration and build it in the usual manner.

    Have fun. Unless there is outpouring from people who love the idea,
    I'm not going to commit these to FreeBSD.

    -- 
    Crist J. Clark                           cjclarkalum.mit.edu
                                             cjclarkjhu.edu
                                             cjcfreebsd.org
    



    To Unsubscribe: send mail to majordomoFreeBSD.org with "unsubscribe freebsd-security" in the body of the message