cryptomancer.de

verified executables
harden your system with veriexec(4)

What is verified executables? (Index)

veriexec adds a new function to the exec-Path of the kernel, thus allowing
the kernel to check a cryptographic hash for a binary. With this feature, it is
almost impossible to run manipulated binaries like a rootkit or a trojan.

How to enable it? (Index)

veriexec has been implemented on NetBSD 2.0 and is available in the
1.6-current developers branch. If you want to test it now, you have to build
a current release with veriexec supported, as described in this Document.
Either you use GENERIC_VERIEXEC or you add 
options VERIFIED_EXEC
#uncomment following 2 lines if you like verbose debugging
#options VERIFIED_EXEC_DEBUG
#options VERIFIED_EXEC_DEBUG_VERBOSE
pseudo-device verifiedexec        1
to your kernel configuration and recompile a new Kernel and Userland.
If you boot into the new Kernel with veriexec enabled, you will receive warning
messages about inappropriate checksums, ignore them until your Userland has been
setup to support veriexec properly.
After installing the new Userland, you are required to create /dev/veriexec with
cd /dev && ./MAKEDEV veriexec
If done so, you should now create a database containing the files and hashes,
using /usr/share/examples/veriexecctl/gen_sha1 as a helper skript.
The system will now generate a file called signatures, containing all
files and fingerprints. It is a good idea to move ./signatures to a
write-protected media, like a floppy or to encrypt or sign it with
e.g. PGP/GnuPGP, to ensure it's integrity.
Copy ./signatures to /etc/ and add 
veriexecctl /etc/signatures
to /etc/rc.local to load the signatures into kernelmemory.
If you reboot now and raise the kernelsecuritylevel to 1, /netbsd warns
of not matching fingerprints for binaries, if you raise the level to 2
/netbsd will refuse to execute binaries with non-matching fingerprints.
Since you are required to use Kernelsecuritylevels, X won't run any longer
on your machine, since it uses memory mapping to /dev/mem to acces your videocard.

Kernel security levels (Index)

Kernel security levels have been introduced back in 4.4 to use file flags as a
mechanism to enhance security. Ususally the system is running at a level 1,
which can be checked with sysctl kern.securelevel, once the level has
been set in the bootup process using the securelevel option in /etc/rc.conf
you cannot lower the level anymore, but you are allowed to raise it to either 1 or 2.
In addition to using file flags, a kernel security level greater than 0 will
also deny any write-access to kernelmemory /dev/mem and /dev/kmem
so it is impossible to manipulate the signatures loaded into kmem,
but you are also required to reboot the machine to use new signatures
e.g. after installing new binaries.

further links (Index)

http://www.free-x.ch/pub/proposal.txt File Flags Proposal
see init(8) and /usr/include/sys/systm.h for information about security levels
$Id: veriexec.html,v 1.2 2004/05/09 11:33:01 stefan Exp $