how to disable loadable kernel moduels?

Robert Bonomi bonomi at
Thu Feb 25 02:49:38 UTC 2010

> From owner-freebsd-questions at  Wed Feb 24 18:04:25 2010
> Date: Wed, 24 Feb 2010 17:38:45 -0600 (CST)
> From: Lars Eighner <luvbeastie at>
> To: Robert Bonomi <bonomi at>
> Cc: questions at
> Subject: Re: how to disable loadable kernel moduels?
> On Wed, 24 Feb 2010, Robert Bonomi wrote:
> > 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>

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 pretty much have to be able
> to reboot the machine, soo...
> It seems to me you could replace kldload (the command, not the system call)
> with a dummy script which would raise the bar a bit.  You could remove (I
> think) the modules you are afraid of, but someone with root priviledges
> could replace them with trojans.

I *can* ensure a 'trusted' software platform at boot time.  I _can't_ ensure
that there are no bugs/points of attack. But I can make 'life difficult' for
the bad actor that does find an exploit. 

Protecting 'critical resources' against someone who gains enough access to 
import his own tools (say his _own_copy_ of kldload) is the threat level I'm 
looking at.  

I _want_ the bad guy to waste his time trying things that "don't work", and that
may set off alarms.  Much better chances of catching the perp 'in the act' when 
he doesn't know that he's triggered something.

More information about the freebsd-questions mailing list