Date: Thu, 25 Feb 2010 13:51:15 +0100 From: Ruben de Groot <mail25@bzerk.org> To: Robert Bonomi <bonomi@mail.r-bonomi.com> Cc: luvbeastie@larseighner.com, questions@freebsd.org Subject: Re: how to disable loadable kernel moduels? Message-ID: <20100225125115.GA20797@ei.bzerk.org> In-Reply-To: <201002250249.o1P2nT9r012045@mail.r-bonomi.com> References: <201002250249.o1P2nT9r012045@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Feb 24, 2010 at 08:49:29PM -0600, Robert Bonomi typed: > > > > > I'm building custom kernels for use in 'hostile' environments -- where I > > > need to enforce "restricted" capabilities, even in the event of malicious > > > 'root' access. (if the bad guy has *physical* access to the machine, I > > > know I'm toast, so I don't try to protect against _that_ in software -- > > > beyond the usual access-control mechnisms, that is.) > > > > > > To accomplish this, I need to (among other things) *completely* disable > > > kernel 'loadable module' functionality. Building the required monolithic > > > kernel is no problem, and by booting from _physical_ read-only media, I > > > can protect against bootloader/kernel/application substitution. I just > > > need to make it "impossible" to add modules to the running system. > > > > I don't see how this is really bullet-proof possible. Anyone with root > > access can edit loader.conf and force a reboot --- or wait until a power > > interuption or something causes a reboot. > > You're not thinking 'creatively' enough. <grin> heheh :) > superuser access _doesn't_ help if things like 'loader.conf' are on _read-only_ > media. Not just a mount switch, but -hardware- enforced. Many SCSI disks have > a 'write-protect' jumper on them. The _only_ way to defeat =that= requires > physical access to the machine. You probably have covered this allready, but consider running all services in a jailed environment, without access to hardware devices (including [k]mem, io etc). With access to /dev/mem, a sufficiently sophisticated attacker can potentially patch your running kernel on the fly. Ruben
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100225125115.GA20797>