Date: Sun, 9 Sep 2001 10:05:54 +0200 (CEST) From: Krzysztof Zaraska <kzaraska@student.uci.agh.edu.pl> To: D J Hawkey Jr <hawkeyd@visi.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: Kernel-loadable Root Kits Message-ID: <Pine.BSF.4.21.0109090918050.457-100000@lhotse.zaraska.dhs.org> In-Reply-To: <20010908171641.A79354@sheol.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 8 Sep 2001, D J Hawkey Jr wrote: > On Sep 08, at 08:07 PM, Krzysztof Zaraska wrote: > > > > On Sat, 8 Sep 2001, D J Hawkey Jr wrote: > > > > But activity in /tmp is normal and will be ignored by tripwire, right? > > Tripwire's policy file can reflect nearly any level of Admin paranoia. Ever seen an admin that would observe changes in /tmp on a daily basis? > > > > We may also consider adding a feature to kldload to load only modules > > > > from under /modules but I'm afraid this may be circumvented by attacker > > > > fetching her own kldload. A better way would be to implement an > > > > appropriate lock in kernel code but I don't know if it's possible. > > Who's the "we"? The FreeBSD project? "We" was intended to mean "anyone involved in this discussion". If you want to read it as "the FreeBSD community such as developers and users" you may. I'm _not_ a FreeBSD project member and therefore "we" cannot refer to the project. > > Or, something LIDS-like. > You're the second to mention LIDS. I know so little about it as to > refrain from comment (like, why should I let that stop me now?). Based > on another's description, it strikes me as rather over-engineered, but > that's an ignorant opinion. Maybe it has to be. Well. I heard about it once, went to their site, read the docs and run away ;). Seriously, it seemed to offer interesting features but all the complications scared me off. > RedHat does seem more dependant on LKMs than FreeBSD and KLDs, at least > out-of-the-box, so perhaps the modules are more of a security issue? This is due to the way Linux bootloader works. The compressed kernel image must fit within the first 640K of memory, so that imposes a limit on the kernel size. Since they want plug-and-play they must have all the existing drivers (save maybe video cards and the like) built. But taking into account the kernel size limit they must be built as modules. FreeBSD also has lots of drivers in the GENERIC kernel (for the similar reason) but this system does not seem to have this kind of limitations. IIRC they are some Linux drivers that _must_ be built as modules for some reason (PPP-related stuff, I guess). I hope this discussion won't end up with advocacy of FreeBSD's superiority to Linux in the area of kernel modules. BTW: is there a way to build linux.ko in the kernel? Or is it a must-be module? > > may be a similar situation in the future, that say some SuperHardware Inc. > > releases it's new 10Gbit ethernet adapter giving away the compiled drivers > > as modules and not releasing the source code nor the hardware > > specifications. In this case you need module support, at least at boot > > time. > > Or, wait for the more open-minded competition that'll be along shortly. > :-) When the device price is around USD10,000 I doubt the existence of open-minded competition (I am not specifically referring to the above example). Not to mention the situation the you need the backward compatibility with some ancient proprietary hardware / software your company bought years ago and the manufacturer went out of business. OK, this is off topic. Just wanted to show that kernel modules may be necessary. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0109090918050.457-100000>