Kernel-level security (was Re: Positive uses for rootkits)

[Craig Boston <craig () aevrf gank org>]

Just a thought, what about the kern.securelevel sysctl mechanism on
FreeBSD/OpenBSD?

If kern.securelevel >= 1, /dev/mem and /dev/kmem cannot be accessed (even by
root), kernel modules cannot be loaded/unloaded, nor can the special device
for mounted filesystems be written to (so you can't use dd to overwrite
random parts of the disk).  Then if you do "chflags schg /kernel", not even
root is allowed to overwrite the kernel.  Be sure to do the same for
everything in /boot/ and /boot.config or the attacker can just name the
kernel something else :)

If kern.securelevel is >= 2, the block devices are further locked down and
can't be written to even if a filesystem is not mounted.  Don't do this on a
system where you need to format floppy disks or you'll pull you hair out
trying to figure out why it won't let you :)

Of course there's probably some way around this that I'm not thinking of,
but it certainly makes things more difficult for a would-be rootkit...

And sure it's a pain to reboot into single-user mode before kernel and
system upgrades, but that's probably a more secure way to do it anyway...

Not sure if NetBSD has this; I don't have it installed anywhere...

Cheers,
Craig

----- Original Message -----
From: "Ryan Permeh" <ryan () EEYE COM>
To: <VULN-DEV () SECURITYFOCUS COM>
Sent: Wednesday, March 28, 2001 11:31 AM
Subject: Re: Positive uses for rootkits


there are kernel debuggers that use /dev/kmem.  using this same methodology,
you could create a inmemory kernel patcher that could inject rootkit code
into a running kernel.
Signed,
Ryan Permeh
eEye Digital Security Team
http://www.eEye.com/Retina -Network Security Scanner
http://www.eEye.com/Iris -Network Traffic Analyzer