> From owner-freebsd-questi...@freebsd.org Wed Feb 24 18:04:25 2010 > Date: Wed, 24 Feb 2010 17:38:45 -0600 (CST) > From: Lars Eighner <luvbeas...@larseighner.com> > To: Robert Bonomi <bon...@mail.r-bonomi.com> > Cc: questi...@freebsd.org > 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. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
