In some email I received from Bakul Shah, they wrote:
> 
> > you have to pay something for security.  to have the concept of
> > securelevel, it means that you lose somethings that are otherwise
> > doable.  this includes the ability to load extra modules as you
> > want.  if you want to be able to do this, then you have to give
> > up the extra security that securelevel gives you.  the ability to
> > load *any* random code into the kernel means you've got the
> > ability to do anything to the system.  securelevel is supposed to
> > stop you from having that -- no write access to /dev/k?mem, or to
> > the disk devices while securelevel > 0.
> 
> (I think)  I understand the *concept* of securelevel; but to
> make your system really secure you also then have to
> disallow auto reboot of any sort because otherwise the bad
> guy can become root, change /etc/rc etc. and reboot such
> that the next time around securelevel is -1.  You have to
> make sure the bad guy does not set things up so that his LKM
> is loaded the next time around because it can defeat
> securelevel by directly reading/writing memory.  He can even
> modify the kernel binary to change securelevel.  I am sure
> there are many other nasty things one can find to do **if
> you assume one can somehow become root**.
> 
> It seems to me that if you restrict things more and more to
> plug holes as they are discovered, people will be tempted to
> just keep the damn door open (ie. set securelevel to -1) all
> the time just so they can get in without too much
> inconvenience; thereby losing whatever extra security was
> available.

Checkout chflags and what these offer.  It is possible to *stop*
people modifying the kernel, /etc/rc*, in multiuser mode already.

For proof of this, create a file in /tmp, set the schg flag and try
remove the file.  Try rebooting, and see what happens when something
tries to remove it whilst cleaning /tmp on reboot.

darren