|
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 (cristjc
earthlink.net)Date: Thu Oct 04 2001 - 04:30:34 CDT
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 cjclark
jhu.edu cjc
freebsd.org
- text/plain attachment: sys_stable.patch
- text/plain attachment: sys_current.patch
To Unsubscribe: send mail to majordomo
FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]