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

_______________________________________________
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"

Reply via email to