Date: Tue, 28 Sep 2004 18:50:39 -0400 From: Deepak Jain <deepak@ai.net> To: cjclark@alum.mit.edu Cc: Alexander Langer <alex@big.endian.de> Subject: Re: Kernel-loadable Root Kits Message-ID: <4159EABF.3030004@ai.net> In-Reply-To: <20011004023034.U8391@blossom.cjclark.org> References: <GPEOJKGHAMKFIOMAGMDIGEHGFHAA.deepak_ai.net@ns.sol.net> <200109081052.f88AqRG30016@sheol.localdomain> <20010908141700.A53738@fump.kawo2.rwth-aachen.de> <20010908072542.A57605@sheol.localdomain> <20010908143231.A53801@fump.kawo2.rwth-aachen.de> <20010908074445.A77252@sheol.localdomain> <20010908181537.A840@ringworld.oblivion.bg> <20010908102816.B77764@sheol.localdomain> <20010908183728.D840@ringworld.oblivion.bg> <20010908105308.A78138@sheol.localdomain> <20011004023034.U8391@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the module, I think its a good idea to commit it to FreeBSD
for a few reasons:
1) Some folks just prefer more static kernels.
2) Securelevel is a great thing, but can be a pain to do upgrades around
remotely. [A lot of folks use FreeBSD simply because its a breeze to run
remotely].
3) Until someone writes code to add modules to a kernel via /dev/mem and
releases it to the script kiddie world, the bar has been effectively
raised for 99% of the miscreants out there.
4) Marketing-wise, it will make folks who don't understand the issues
very deeply more comfortable. And as in #3, that is probably a 99%
accurate feeling.
5) For those of us using automatic updating systems, having modules and
kernels out of sync is bad potentially, so NO_KLD helps keep that from
being an issue.
Just my thoughts, we will be patching roughly 5,000 machines for this in
our first round of deployments.
Deepak Jain
AiNET
Crist J. Clark wrote:
> 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.
>
>
> ------------------------------------------------------------------------
>
> Index: sys/conf/options
> ===================================================================
> RCS file: /export/ncvs/src/sys/conf/options,v
> retrieving revision 1.191.2.36
> diff -u -r1.191.2.36 options
> --- sys/conf/options 2001/09/15 00:50:35 1.191.2.36
> +++ sys/conf/options 2001/10/04 08:21:10
> @@ -464,3 +464,6 @@
> FDC_DEBUG opt_fdc.h
> PCFCLOCK_VERBOSE opt_pcfclock.h
> PCFCLOCK_MAX_RETRIES opt_pcfclock.h
> +
> +# Disable loading and unloading of kernel modules
> +NO_KLD opt_kern_linker.h
> Index: sys/kern/kern_linker.c
> ===================================================================
> RCS file: /export/ncvs/src/sys/kern/kern_linker.c,v
> retrieving revision 1.41.2.2
> diff -u -r1.41.2.2 kern_linker.c
> --- sys/kern/kern_linker.c 2000/07/16 13:13:32 1.41.2.2
> +++ sys/kern/kern_linker.c 2001/10/04 08:10:05
> @@ -27,6 +27,7 @@
> */
>
> #include "opt_ddb.h"
> +#include "opt_kern_linker.h"
>
> #include <sys/param.h>
> #include <sys/kernel.h>
> @@ -648,6 +649,10 @@
> int
> kldload(struct proc* p, struct kldload_args* uap)
> {
> +#ifdef NO_KLD
> + /* Always return error. */
> + return EPERM;
> +#else
> char* filename = NULL, *modulename;
> linker_file_t lf;
> int error = 0;
> @@ -685,11 +690,16 @@
> if (filename)
> free(filename, M_TEMP);
> return error;
> +#endif
> }
>
> int
> kldunload(struct proc* p, struct kldunload_args* uap)
> {
> +#ifdef NO_KLD
> + /* Always fail. */
> + return EPERM;
> +#else
> linker_file_t lf;
> int error = 0;
>
> @@ -716,6 +726,7 @@
>
> out:
> return error;
> +#endif
> }
>
> int
>
>
> ------------------------------------------------------------------------
>
> Index: sys/conf/options
> ===================================================================
> RCS file: /export/ncvs/src/sys/conf/options,v
> retrieving revision 1.295
> diff -u -r1.295 options
> --- sys/conf/options 2001/09/29 22:32:00 1.295
> +++ sys/conf/options 2001/10/04 08:07:37
> @@ -526,3 +527,6 @@
>
> # ed driver
> ED_NO_MIIBUS opt_ed.h
> +
> +# Disable loading and unloading of kernel modules
> +NO_KLD opt_kern_linker.h
> Index: sys/i386/conf/NOTES
> ===================================================================
> RCS file: /export/ncvs/src/sys/i386/conf/NOTES,v
> retrieving revision 1.961
> diff -u -r1.961 NOTES
> --- sys/i386/conf/NOTES 2001/09/29 22:31:57 1.961
> +++ sys/i386/conf/NOTES 2001/10/04 08:07:51
> @@ -106,6 +106,10 @@
> #
> options ROOTDEVNAME=\"ufs:da0s2e\"
>
> +# This prevents KLDs from being loaded at all. For those who want the
> +# added security but cannot run at an elevated securelevel(8).
> +#options NO_KLD
> +
>
> #####################################################################
> # SMP OPTIONS:
> Index: sys/kern/kern_linker.c
> ===================================================================
> RCS file: /export/ncvs/src/sys/kern/kern_linker.c,v
> retrieving revision 1.69
> diff -u -r1.69 kern_linker.c
> --- sys/kern/kern_linker.c 2001/09/12 08:37:44 1.69
> +++ sys/kern/kern_linker.c 2001/10/04 07:47:05
> @@ -27,6 +27,7 @@
> */
>
> #include "opt_ddb.h"
> +#include "opt_kern_linker.h"
>
> #include <sys/param.h>
> #include <sys/kernel.h>
> @@ -685,6 +686,10 @@
> int
> kldload(struct thread* td, struct kldload_args* uap)
> {
> +#ifdef NO_KLD
> + /* Always fail */
> + return EPERM;
> +#else
> char *kldname, *modname;
> char *pathname = NULL;
> linker_file_t lf;
> @@ -727,6 +732,7 @@
> free(pathname, M_TEMP);
> mtx_unlock(&Giant);
> return (error);
> +#endif
> }
>
> /*
> @@ -735,6 +741,10 @@
> int
> kldunload(struct thread* td, struct kldunload_args* uap)
> {
> +#ifdef NO_KLD
> + /* Always fail */
> + return EPERM;
> +#else
> linker_file_t lf;
> int error = 0;
>
> @@ -764,6 +774,7 @@
> out:
> mtx_unlock(&Giant);
> return (error);
> +#endif
> }
>
> /*
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4159EABF.3030004>