it-swarm.com.de

Signierte ausführbare Dateien unter Linux

Aus Sicherheitsgründen ist es wünschenswert, die Integrität des Codes vor der Ausführung zu überprüfen. Manipulation von Software durch einen Angreifer vermeiden. Meine Frage ist also

Wie kann ich ausführbaren Code signieren und nur vertrauenswürdige Software unter Linux ausführen?

Ich habe die Arbeit von van Doom et al., Design und Implementierung von signierten ausführbaren Dateien für Linux und von IBMs TLC (Trusted Linux Client) von Safford gelesen & Sohar. TLC verwendet den TPM-Controller, was Nice ist, aber das Papier stammt aus dem Jahr 2005 und ich konnte keine aktuellen Alternativen finden.

Kennen Sie andere Möglichkeiten?

UPDATE: Und über andere Betriebssysteme? OpenSolaris? BSD-Familie?

29
TH.

Das DigSig Kernel-Modul implementiert die Überprüfung von Binärdateien, die von einem Tool namens bsign signiert wurden. Seit der Version 2.6.21 des Linux-Kernels wurde jedoch nichts daran gearbeitet.

5
hillu

Mir ist klar, dass dies eine alte Frage ist, aber ich habe sie gerade erst gefunden.

Ich habe vor einiger Zeit signierte ausführbare Dateien für den Linux-Kernel (um Version 2.4.3) geschrieben und hatte die gesamte Toolchain zum Signieren von ausführbaren Dateien, Überprüfen der Signaturen zum Zeitpunkt execve(2) und Zwischenspeichern der Signaturvalidierungsinformationen (Löschen der Validierung, wenn die Datei zum Schreiben geöffnet oder auf andere Weise geändert wurde), Einbetten der Signaturen in beliebige ELF-Programme usw. Bei der ersten Ausführung jedes Programms wurden einige Leistungseinbußen eingeführt (da der Kernel in ) geladen werden musste + gesamte Datei, anstatt nur die benötigten Seiten anzufordern, aber sobald sich das System in einem stabilen Zustand befand, funktionierte es gut.

Wir haben uns jedoch dazu entschlossen, die Verfolgung einzustellen, da es einige Probleme gab, die die Komplexität nicht rechtfertigen konnten:

  • Wir haben noch keine Unterstützung für signierte Bibliotheken erstellt. Signierte Bibliotheken müssten auch den Loader ld.so und den Mechanismus dlopen(3) modifizieren. Dies war nicht unmöglich, erschwerte aber die Benutzeroberfläche: Soll der Loader den Kernel auffordern, eine Signatur zu validieren, oder sollte die Berechnung vollständig im Benutzerbereich erfolgen? Wie kann man sich vor einem strace(2)d-Prozess schützen, wenn dieser Teil der Validierung im Userspace erfolgt? Würden wir gezwungen sein, strace(2) auf einem solchen System vollständig zu verbieten?

    Was würden wir mit Programmen machen, die einen eigenen Loader liefern?

  • Sehr viele Programme sind in Sprachen geschrieben, die nicht zu ELF-Objekten kompiliert werden können. Wir müssten sprachspezifische Änderungen an bash, Perl, python, Java, awk, sed usw., damit jeder der Interpreter auch Signaturen validieren kann. Da es sich bei den meisten dieser Programme um Freiformat-Klartext handelt, fehlt ihnen die Struktur, die das Einbetten digitaler Signaturen in ELF-Objektdateien so einfach macht. Wo würden die Unterschriften aufbewahrt? In den Skripten? In erweiterten Attributen? In einer externen Signaturdatenbank?

  • Viele Dolmetscher sind wide open darüber, was sie zulassen; bash(1) kann über echo und /dev/tcp mit fernen Systemen kommunizieren ganz alleine und kann leicht dazu verleitet werden, die von Angreifern benötigten Aktionen auszuführen tun. Signiert oder nicht, man konnte ihnen nicht vertrauen, als sie unter der Kontrolle eines Hackers waren.

  • Der Hauptgrund für die Unterstützung signierter ausführbarer Dateien sind Rootkits, die den vom System bereitgestellten /bin/ps, /bin/ps, /bin/kill usw. ersetzen. Ja, es gibt andere nützliche Gründe, ausführbare Dateien signiert zu haben. Rootkits wurden jedoch mit der Zeit erheblich beeindruckender, da sich viele auf Kernel Hacks stützten, um ihre Aktivitäten vor Administratoren zu verbergen. Sobald der Kernel gehackt wurde, ist das ganze Spiel vorbei. Aufgrund der Raffinesse der Rootkits gerieten die Tools, von denen wir hofften, dass sie nicht verwendet werden, in der Hacking-Community in Ungnade.

  • Die Ladeschnittstelle des Kernels war weit offen. Sobald ein Prozess die Berechtigung root hat, war es einfach, ein Kernelmodul ohne Prüfung einzufügen. Wir hätten auch einen weiteren Verifizierer für Kernelmodule schreiben können, aber die Infrastruktur des Kernels um Module war sehr primitiv.

57
sarnold

Das GNU/Linux/FOSS-Modell fördert tatsächlich Manipulationen - gewissermaßen. Benutzer und Distributoren müssen die Software an ihre Bedürfnisse anpassen können. Sogar das Neukompilieren der Software (ohne Änderung des Quellcodes) zur Anpassung wird häufig durchgeführt, würde jedoch die Binärcode-Signatur unterbrechen. Daher ist das Binärcode-Signaturmodell nicht besonders gut für GNU/Linux/FOSS geeignet.

Stattdessen ist diese Art von Software mehr auf das Generieren von Signaturen und/oder sicheren Hashes der Quellpakete angewiesen. In Kombination mit einem zuverlässigen und vertrauenswürdigen Paketverteilungsmodell kann dies ebenso sicher gemacht werden (wenn nicht mehr gegenüber der Transparenz in den Quellcode) wie die binäre Codesignierung.

11
Dan Moulding

Schauen Sie sich das an: http://linux-ima.sourceforge.net/

Es ist noch nicht signiert, ermöglicht aber trotzdem eine Überprüfung.

4
viraptor

Ich kann die Frage aus der Sicht von Solaris 10 und 11 beantworten. Alle Binärdateien sind signiert. Um die Signatur zu überprüfen, verwende 'elfsign' ...

$ elfsign verify -v /usr/bin/bash
elfsign: verification of /usr/bin/bash passed.
format: rsa_sha1.
signer: O=Oracle Corporation, OU=Corporate Object Signing, OU=Solaris Signed Execution, CN=Solaris 11.
signed on: Fri Oct 04 17:06:13 2013.

Oracle hat kürzlich auch einen verifizierten Startvorgang für Solaris 11 hinzugefügt. Weitere Informationen finden Sie unter - Von Solaris verifizierte Booteinführung

Für den OpenSolaris-Code gibt es einige Gabeln für die Produktionsqualität.

3
Brainz

Schauen Sie sich die Medusa DS9 an. Ich habe vor langer Zeit damit gespielt ( long ), aber wenn ich mich recht erinnere, konnte man bestimmte Binaries registrieren und jede Änderung war auf der Kernelebene nicht erlaubt. Natürlich kann es mit lokalem Zugriff auf die Maschine außer Kraft gesetzt werden, aber es war nicht wirklich einfach. Es gibt einen intelligenten Daemon namens constable, der alles überprüft, was auf dem Computer passiert. Wenn etwas Ungewöhnliches passiert, fängt es an zu schreien.

2
Stefano Borini

Ich habe es noch nie probiert, aber schau mal nach: http://blog.codenoise.com/signelf-digitally-signing-elf-binaries . Die Lösung funktioniert ohne Kernel-Unterstützung und scheint bereit zu sein.

Den Code für den Unterzeichner finden Sie unter http://sourceforge.net/projects/signelf/

Es löst nicht die Frage "Nur vertrauenswürdigen Code auf Linux ausführen", aber es löst das Problem teilweise, indem es dem Programm ermöglicht wird, eine mögliche Manipulation/Beschädigung zu erkennen

2
Gabriel Mazetto

http://en.wikipedia.org/wiki/PKCS

Verwenden Sie ein PKCS7-Zeichen (S/MIME). Generieren Sie Ihr eigenes Zertifizierungsschlüssel/Privaten Schlüsselpaar, signieren Sie das Zertifizierungszeichen selbst und signieren Sie dann Ihre Datei mit dem privaten Schlüssel und dem Zertifizierungszeichen mit PKCS7. Das Zertifikat wird an dieses angehängt, und es kann sich zur Laufzeit mit dem Befehl openssl überprüfen (man smime oder einfach die openssl-Hilfe ausführen). Dies ist manipulationssicher, da die S/MIME-Signatur für diesen öffentlichen Schlüssel, obwohl sich der öffentliche Schlüssel in den von Ihnen ausgegebenen Dateien befindet, nur mit dem privaten Schlüssel generiert werden kann, den Sie nicht verteilen. Wenn die Datei also von Ihrem cert signiert wurde, muss sie von jemandem mit dem privaten Schlüssel signiert worden sein. Da Sie den privaten Schlüssel nicht an Dritte weitergegeben haben, muss er von Ihnen stammen.

So erstellen Sie das selbstsignierte Zertifikat.

http://www.akadia.com/services/ssh_test_certificate.html

Sie müssen openssl davon überzeugen, dass Sie Ihrem cert als Root of Authority (-CAfile) vertrauen, es dann als root überprüfen und auch überprüfen, ob das cert in der Datei Ihnen gehört (hash das cert) und den Hash überprüfen. Obwohl es nicht dokumentiert ist, spiegelt der Exit-Status von openssl die Gültigkeit des Zeichens wider, das Sie bei einer Smime-Überprüfung überprüfen. Es ist 0, wenn es passt, nicht Null, wenn es nicht passt.

Beachten Sie, dass dies alles nicht sicher ist, denn wenn die Prüfung in Ihrem Code enthalten ist, können sie die Prüfung einfach entfernen, wenn sie Sie schlagen möchten. Der einzige sichere Weg, dies zu tun, wäre, den Checker im Betriebssystem zu haben und Ihre Binärdatei überprüfen zu lassen und die Ausführung abzulehnen, wenn er nicht signiert ist. Aber da es im OS keinen Checker gibt und Linux geändert werden kann, um es trotzdem zu entfernen/zu umgehen ... Was wirklich gut ist, ist das Erkennen beschädigter Dateien mehr als der Versuch, die Leute daran zu hindern, Sie zu umgehen.

Ich denke gerne an Sicherheit als Kette. Das schwächere Glied der Kette kann das gesamte System beeinträchtigen. Das Ganze wird also zu "verhindert, dass ein nicht autorisierter Benutzer das root-Passwort erhält").

Wie von @DanMoulding vorgeschlagen, ist auch die Quelle der Software wichtig, und in der Zukunft werden wahrscheinlich offizielle OS-Anwendungsspeicher der Standard sein. Denken Sie an Play Store, Apple oder Microsoft Stores.

Ich denke, dass die Installation und Verbreitung von verdecktem bösartigem Code das weitaus heimtückischere Problem ist. Um fehlerhaften Code zu laden, muss er zuerst irgendwo auf dem System installiert werden. Natürlich sind mehr Sicherheitsschichten normalerweise besser. Die Frage ist: Ist es die Kosten wert?

Meiner Meinung nach lautet die Antwort "es kommt darauf an". Sie können das Risiko reduzieren, indem Sie eine Reihe von Sicherheitsrichtlinien übernehmen, wie von @sleblanc vorgeschlagen. Sie können Ihr Dateisystem verschlüsseln ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ), schreibgeschützte Dateisysteme für die Binärdateien verwenden oder einen Mechanismus zum Signieren und Überprüfen der Binärdateien verwenden.

Unabhängig davon, welchen Mechanismus Sie verwenden, können Sie nichts tun, sobald der Root-Zugriff von einem Angreifer erlangt wird. Die Signaturüberprüfungs-Tools können durch eine manipulierte Version ersetzt oder einfach deaktiviert werden. Es spielt keine Rolle, ob die Tools im Benutzer- oder Kernel-Space ausgeführt werden, sobald die Maschine gefährdet ist (obwohl letzteres natürlich sicherer wäre.) ).

Es wäre also schön, wenn der Linux-Kernel ein Signaturüberprüfungsmodul und eine weitere Sicherheitsschicht zwischen dem Rootbenutzer und dem Betriebssystem einbetten könnte.

Dies ist zum Beispiel der Ansatz, der in den letzten Versionen von macOS verwendet wurde. Einige Dateien können nicht vom Root-Konto aus geändert (und manchmal auch gelesen) werden, und auch die Richtlinien und Kernel-Module unterliegen Einschränkungen (z. B. kann nur signierter oder autorisierter Kext auf das System geladen werden). Windows übernahm mehr oder weniger den gleichen Ansatz wie AppLocker.

0
Bemipefe

Ich stimme zu, dass die Philosophie um Linux, GNU et al. dreht sich um basteln. Andererseits glaube ich auch, dass einige Systeme Schutz vor Schwachstellen wie beispielsweise Manipulation von Software verdienen, was die Privatsphäre und Integrität der Benutzer eines Systems beeinträchtigen kann.

Kernel-Implementierungen können mit dem schnellen Entwicklungszyklus des Kernels selbst nicht Schritt halten. Ich empfehle stattdessen, eine Form der Überprüfung der Signatur von ausführbaren Dateien mithilfe von Userspace-Tools zu implementieren. Platzieren Sie ausführbare Dateien in einem Archiv- oder Dateisystem-Image und signieren Sie das Image mit einem privaten Schlüssel. Wenn dieser private Schlüssel auf Ihren Entwicklungscomputern verbleibt (privat), haben Angreifer nach dem Hacken Ihres Servers immer noch keine Möglichkeit, ihre eigenen Images zu signieren und ihren Code einzufügen, ohne das System dazu zu bewegen, unsignierte Images bereitzustellen. Es erstreckt sich weiter entlang der Kette:

  • lassen Sie Ihre Dienste in Laufzeit-Read-Only-Images enthalten.
  • die Maschine von einem signierten, schreibgeschützten Dateisystem ablaufen lassen;
  • implementieren Sie einen sicheren Start auf Ihren Maschinen, indem Sie einen Bootloader ausführen, der die Integrität des Startmediums erzwingt.
  • vertrauen Sie darauf, dass die Mitarbeiter Ihres Unternehmens Ihre Maschinen nicht manipulieren.

Alles richtig zu machen ist ein hartes Unterfangen. Es ist viel einfacher, dies zu umgehen, indem Sie Ihr System unter einem anderen Ansatz gestalten:

  • benutzer aus dem System unter Quarantäne stellen. Führen Sie keine Mittel für Benutzer ein, um Befehle auf Ihrem System auszuführen. Vermeiden Sie das Ausschalten von Programmen, die auf vom Benutzer eingespeisten Daten basieren.
  • entwerfen Sie Ihre Bereitstellungsverfahren mithilfe des Konfigurationsmanagements und stellen Sie sicher, dass Ihre Bereitstellungen "wiederholbar" sind. Dies bedeutet, dass sie bei mehrmaliger Bereitstellung zum gleichen funktionalen Ergebnis führen. Auf diese Weise können Sie Maschinen, von denen Sie vermuten, dass sie gefährdet sind, "aus dem Orbit" schleudern.
  • behandeln Sie Ihre Maschinen so, als wären sie gefährdet: Führen Sie regelmäßig Audits durch, um die Integrität Ihrer Systeme zu überprüfen. Speichern Sie Ihre Daten auf separaten Images und stellen Sie Systeme regelmäßig neu bereit. Zeichenbilder und Systeme weisen vorzeichenlose Bilder zurück.
  • verwenden Sie Zertifikate: Bevorzugen Sie einen "Certificate Pinning" -Ansatz. Stellen Sie für Ihre Anwendungen ein Stammzertifikat bereit (das die automatische Zurückweisung von Signaturen ermöglicht, die von Ihrer Organisation nicht zertifiziert wurden). Das System muss jedoch mindestens Fingerabdrücke der aktuellen Bilder verwalten und Administratoren benachrichtigen, wenn sich Fingerabdrücke geändert haben. Obwohl dies alles mithilfe von Schlüsselketten implementiert werden kann, wurde die zertifikatbasierte Authentifizierung für diese genaue Anwendung entwickelt.
0
sleblanc