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.

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 <a href="http://www.netbsd.org/Documentation/current/">Document</a>. Either you use GENERIC_VERIEXEC or you add

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

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 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.