File:  [NetBSD Developer Wiki] / wikisrc / Attic / veriexec.mdwn
Revision 1.2: download - view: text, annotated - select for diffs
Sun Feb 5 07:14:36 2012 UTC (8 years, 5 months ago) by schmonz
Branches: MAIN
CVS tags: HEAD
dos2unix

    1: **Contents**
    2: 
    3: [[!toc levels=3]]
    4: 
    5: ##  What is verified executables?
    6: 
    7: 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. 
    8: 
    9: #  How to enable it?
   10: 
   11: 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 
   12:     
   13:     options VERIFIED_EXEC
   14:     #uncomment following 2 lines if you like verbose debugging
   15:     #options VERIFIED_EXEC_DEBUG
   16:     #options VERIFIED_EXEC_DEBUG_VERBOSE
   17:     pseudo-device verifiedexec 1 
   18:     
   19: 
   20: 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 
   21:     
   22:     cd /dev && ./MAKEDEV veriexec
   23:     
   24: 
   25: 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. 
   26: 
   27: To generate a default signatures file fingerprinting your system files: 
   28:     
   29:     veriexecgen -A -D
   30:     
   31: 
   32: This will create a good base for your signatures file. 
   33: 
   34: #  Strict levels 
   35: 
   36: ##  Level 0 
   37: 
   38: 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. 
   39: 
   40: ##  Level 1 
   41: 
   42: 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. 
   43: 
   44: ##  Level 2 
   45: 
   46: 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). 
   47: 
   48: ##  Level 3 
   49: 
   50: 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. 
   51: 
   52: #  Using together with secure levels 
   53: 
   54: 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. 
   55: 
   56: See [[Kernel secure levels]] for more details. 
   57: 
   58: 
   59: #  Further links
   60: 
   61:   * [http://www.netbsd.org/guide/en/chap-veriexec.html](http://www.netbsd.org/guide/en/chap-veriexec.html) - A chapter in the NetBSD guide 
   62:   * [http://www.free-x.ch/pub/proposal.txt](http://www.free-x.ch/pub/proposal.txt) - File Flags Proposal 
   63:   * See [init(8)](http://netbsd.gw.com/cgi-bin/man-cgi?init+8+NetBSD-current) and [/usr/src/sys/sys/systm.h](http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/src/sys/sys/systm.h?rev=1.183.2.1;content-type=text%2Fx-cvsweb-markup) for information about security levels 
   64:   * For securelevel in combination with X see also the program [sysutils/aperture](http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/pkgsrc/sysutils/aperture/)
   65: 

CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb