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. If you want to enable veriexec on your system, you have to build a 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 ./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.
To generate a default signatures file fingerprinting your system files:
veriexecgen -A -D
This will create a good base for your signatures file.
In strict level 0, learning mode, Veriexec will act passively and simply warn about any anomalies. Combined with verbose level 1, running the system in this mode can help you fine-tune the signatures file. This is also the only strict level in which you can load new entries to the kernel.
Strict level 1, or IDS mode, will deny access to files with a fingerprint mismatch. This mode suits mostly to users who simply want to prevent access to files which might've been maliciously modified by an attacker.
Strict level 2, IPS mode, takes a step towards trying to protect the integrity of monitored files. In addition to preventing access to files with a fingerprint mismatch, it will also deny write access and prevent the removal of monitored files, and enforce the way monitored files are accessed. (as the signatures file specifies).
Lockdown mode (strict level 3) can be used in highly critical situations such as custom made special-purpose machines, or as a last line of defense after an attacker compromised the system and we want to prevent traces from being removed, so we can perform post-mortem analysis. It will prevent the creation of new files, and deny access to files not monitored by Veriexec.
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.
See Kernel secure levels for more details.