harden your system with veriexec(4)

[kaishakunin]

Hi,

ich habe heute mal einen neuen Text für meine Seite verfasst, dabei geht es um verified executables. Der Text ist in Englisch gehalten, was IMO kein Problem sein sollte, ich hätte aber gerne etwas Feedback, da ich mit diesem Thema selbst bei nicht ganz unbedarften Freunden so meine Erklärungsschwierigkeiten hatte.

So denn,
Viel Spass am Gerät.

###########
- What is verified executables?
- How to enable it?
- Kernel security levels
- further links

- 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

 

[Maledictus]

Nicht schlecht!
Die Idee ist so Simpel wie Effektiv.
Ich hatte keine Schwierigkeiten das zu verstehen.

Für den Desktop ja leider nicht zu gebrauchen (da kein X möglich), aber für den Servereinsatz sehr interessant.
Eine Idee, die mir ganz spontan dazu kommt:
Warum nicht die ausführbaren Dateien kryptographisch signieren, und nur signierte Dateien ausführen (in Security Level 2).
(keine Ahnung, ob das mit ELF möglich ist, denke aber schon)
Das würde die Hashtable ersparen.
Man müsste allerdings den Schlüssel im Kernel aufbewahren.
Es hätte den weiteren Vorteil, dass man auch im laufenden Betrieb neue Dateien signieren kann.

gruss
Male

 

[kaishakunin]

Original geschrieben von Maledictus

Eine Idee, die mir ganz spontan dazu kommt:
Warum nicht die ausführbaren Dateien kryptographisch signieren, und nur signierte Dateien ausführen (in Security Level 2).
(keine Ahnung, ob das mit ELF möglich ist, denke aber schon)
Das würde die Hashtable ersparen.
Man müsste allerdings den Schlüssel im Kernel aufbewahren.
Es hätte den weiteren Vorteil, dass man auch im laufenden Betrieb neue Dateien signieren kann.

An der Idee bastel ich schon rum :-)

Man könnte ein asymmetrisches Verfahren wie RSA verwenden und die SHA1 Prüfsumme verschlüsseln und als Datei ablegen, quasi sowas wie
$gpg -a -b
so das es zum Binary eine Signatur auf Festplatte gibt.
Dann muss anstatt dem "einfachen" generieren der Prüfsumme wie bei veriexec diese Prüfsumme noch mit der entschlüsselten Vergleichsprüfsumme verglichen werden.
Dazu müsste man theoretisch nicht mal den Schlüssel in den Kernel packen, sondern nur dessen ID und Fingerprint und die Datei mit dem öffentlichen Sclüssel an geeigneter Stelle ablegen.

Dazu braucht man nicht mal Kernel sec levels, sondern es würde reichen diese Option im Kernel zu aktivieren und jede Ausührung bei einer falschen Sig zu verweigern, neue Binaries muss root dann nur noch mit dem passenden Privatschlüssel (der entsprechend geschützt ist) signieren und man kann diese wieder ausführen.


Ich habe mich auf dem 20C3 mit IIRC Sebastian Schoeberl darüber unterhalten, er wollte für seine pfw (http://www.myshell.de/data/pfw.htm) eine bessere Userkontrolle. Man könnte dan sogar für jeden User eigene Schlüsselpaare verwenden, so das selbst bei einem su zu einem anderen User dessen Schlüssel notwendig ist.
Aber das ist allerding noch Zukunftsmusik :-)

 

[heiko]

Anmerkung zu kern.securelevel und X:
Auch mit securelevel > 0 lässt sich NetBSD noch mit X betreiben. Dazu braucht man sysutils/aperture. Das funktioniert zumindest in den Versionen 1.6.x

 

[sammy2ooo]

der Text ist top. Hab ich gleich angewendet

Ich war eben auf der Suche nach einem gleichwertigen Feature für OpenBSD. Bin dabei auf Stepahine (http://www.innu.org/~brian/Stephanie/ ) gestoßen. Leider unterstützen diese Patches nur OBSD 3.6 Weiß vielleicht jemand von Patches für 3.8? Das Projekt wurde nämlich eingestellt
Ehrlich gesagt verstehe ich nicht so richtig warum die Dev's von OBSD sowas nicht per default in den Kernel integrieren.

 

[crotchmaster]

Ehrlich gesagt verstehe ich nicht so richtig warum die Dev's von OBSD sowas nicht per default in den Kernel integrieren.

Weil die sich für die 'absoluten Chef-Entwickler' halten und die anderen alles 'Idioten' sind.
Jedenfalls kommt mir das so vor, wenn ich deren Sprüche höre o. lese. Das betrifft so einiges bei OpenBSD.

Gruß c.

 

[sammy2ooo]

jo, das Gefühl werde ich irgendwie auch nicht los. Inwiefern unterscheidet sich eigentlich der OpenBSD Kernel vom NetBSD Kernel genau in Bezug auf die sicherheitsrelevanten Features?

Das sind die Features die OpenBSD anpreist

# strlcpy() and strlcat()
# Memory protection purify

* W^X
* .rodata segment
* Guard pages
* Randomized malloc()
* Randomized mmap()
* atexit() and stdio protection

# Privilege separation
# Privilege revocation
# Chroot jailing
# New uids
# ProPolice
# ... and others

...die Website von NetBSD drückt sich hier etwas schwammig aus.

Security (top)

NetBSD has the least number of security bugs reported in any public forums (such as bugtraq). We believe in security without the hype. We do manual code audits and add extended checking capabilities to our toolchain. Retrieval of kernel data is geared towards a sysctl based approach, as opposed to the traditional Unix based kmem access, which requires full access to the whole system, and is often exploited.

...und ja, bevor wilde Diskussionen entstehen, ich weiß das man sowohl ein NetBSD, OpenBSD oder FreeBSD oder was auch immer "sicher" konfigurieren/patchen kann, wenn es nicht schon per default sicher ist.
Mir gehts hier wirklich nur um die "default" Features die die verschiedenen *BSD Kernels mitbringen.

Gruß

 

[crotchmaster]

jo, das Gefühl werde ich irgendwie auch nicht los. Inwiefern unterscheidet sich eigentlich der OpenBSD Kernel vom NetBSD Kernel genau in Bezug auf die sicherheitsrelevanten Features?

OT: Ketzerisch gesagt: Im Hype?

NetBSD macht auch Code-Audits, das ist aber nicht so bekannt wie bei OpenBSD. Und verified exec finde ich auch eine gute Idee, die Sicherheit eines Systems zugewährleisten.

Gruß c.