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 _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[email protected]"
