Signed ausführbare Dateien unter Linux

StackOverflow https://stackoverflow.com/questions/1732927

Frage

Aus Sicherheitsgründen ist es wünschenswert, um die Integrität des Codes vor der Ausführung zu überprüfen, Vermeiden manipulierte Software von einem Angreifer. Also, meine Frage ist

Wie ausführbaren Code zu unterzeichnen und nur vertrauenswürdige Software unter Linux?

run

Ich habe die Arbeit von van Doom lesen et al Design und Implementierung von signierten ausführbaren Dateien für Linux , und die IBM TLC (Trusted Linux-Client) von Safford & Zohar. TLC verwendet TPM-Controller, was schön ist, aber das Papier ist aus dem Jahr 2005, und ich war nicht in der Lage aktuelle Alternativen zu finden.

Kennen Sie weitere Optionen?

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

War es hilfreich?

Lösung

Die DigSig Kernel-Modul implementiert Überprüfung von Binärdateien von einem Tool namens bsign unterzeichnet. Allerdings hat es keine Arbeit auf es seit Version 2.6.21 des Linux-Kernels.

Andere Tipps

Ich weiß, das eine alte Frage, aber ich fand es einfach jetzt.

schrieb ich ausführbare Unterstützung für den Linux-Kernel signiert (um Version 2.4.3) eine Weile zurück, und hatte die gesamte Toolkette anstelle für ausführbare Dateien Unterzeichnung, die Unterschriften bei execve(2) Zeit überprüft, Caching der Validierungsdaten der Signatur (Löschen der Validierung wenn die Datei zum Schreiben oder anderweitig modifiziert) eröffnet wurde, die Unterschriften in beliebige ELF-Programme einbetten, etc. Es hat einige Leistungseinbußen bei der ersten Ausführung jedes Programm einführen (da der Kernel zu laden in der hatte ganze Datei, und nicht nur nachfrage Seite der benötigten Seiten), aber sobald das System war in einem stationären Zustand, es hat gut funktioniert.

Aber wir beschlossen, zu verfolgen, ihn zu stoppen, weil es einige Probleme konfrontiert, die zu groß waren die Komplexität zu rechtfertigen:

  • Wir hatten noch nicht gebaut Unterstützung für unterzeichnet Bibliotheken . Signed Bibliotheken würden auch den ld.so Lader und den dlopen(3) Mechanismus zu verändern. Das war nicht unmöglich, aber tat komplizieren die Schnittstelle: sollten wir die Lade fragt den Kernel haben eine Unterschrift zu bestätigen oder die Berechnung sollte vollständig im Userspace zu tun? Wie würde man gegen einen strace(2)d Prozess schützen, wenn dieser Teil der Validierung in User-Space getan wird? Würden wir gezwungen werden strace(2) ganz auf ein solches System zu verbieten?

    Was würden wir tun, über Programme, die ihre eigenen loader liefern ?

  • Sehr viele Programme sind in Sprachen geschrieben, die kompilieren nicht zu ELF-Objekte. Wir müssten bieten sprachspezifische Änderungen an bash, perl, python, java, awk, sed, und so weiter, für jeden der Dolmetscher in der Lage sein auch Validate Unterschriften. Da die meisten dieser Programme frei Format Klartext sind fehlt ihnen die Struktur, die so einfach zu digitalen Signaturen in ELF-Objektdateien einbetten gemacht. Wo würden die Unterschriften gespeichert? In den Skripten? In der erweiterten Attribute? In einer externen Datenbank von Signaturen?

  • Viele Dolmetscher sind offen über das, was sie können; bash(1) kann mit Remote-Systemen kommunizieren ganz auf seinem eigenen mit echo und /dev/tcp, und einfach in der Ausführung etwas dazu verleitet wird, kann ein Angreifer getan werden muss. Unterzeichnet oder nicht, könnten Sie ihnen nicht trauen, wenn sie unter der Kontrolle eines Hacker waren.

  • Die wichtigste Motivator für die Unterstützung unterzeichnet Executables kommt von Rootkits Austausch des System bereitgestellte /bin/ps, /bin/ps, /bin/kill, und so weiter. Ja, es gibt andere nützliche Gründe unterzeichneten ausführbare Dateien zu haben. Rootkits jedoch bekommt deutlich mehr beeindruckend im Laufe der Zeit, mit vielen sich auf kernel Hacks ihre Aktivitäten von Administratoren zu verstecken. Sobald der Kernel gehackt wurde, ist das ganze Spiel über. Als Folge der Komplexität von Rootkits die Werkzeuge, die wir zu verhindern, hatten gehofft, werden verwendet, fielen aus Bevorzugung in der Hacker-Community.

  • Der Modul-Lade Schnittstelle des Kernels war weit offen. Sobald ein Prozess root Privileg hat, war es einfach, eine Kernel-Modul ohne Überprüfung zu injizieren. Wir könnten auch einen anderen Prüfer für Kernel-Module geschrieben, aber die Infrastruktur des Kernels um Module war sehr primitiv.

Das GNU / Linux / FOSS Modell tatsächlich fördert Manipulation - eine Art. Benutzer und Distro-Entscheidungsträger müssen zu ändern frei (Tamper mit), um die Software, um ihre Bedürfnisse anzupassen. Auch nur die Software neu zu kompilieren (ohne einen Quellcode zu verändern), die individuell gestaltet ist etwas, das recht häufig gemacht wird, würde aber Binär-Code-Signierung brechen. Als Ergebnis wird das binäre Codesignaturmodell nicht besonders gut geeignet, um GNU / Linux / FOSS.

Stattdessen setzt diese Art von Software mehr auf der Generierung von Signaturen und / oder sicheren Hash-Werten der Quellpakete. (Wenn nicht mehr so, gegenüber Transparenz in den Quellcode) als Binär-Code-Signierung in Kombination mit einem zuverlässigen und Paketverteilungsmodell vertraute, kann dies genauso sicher gemacht werden.

Haben Sie einen Blick auf diese: http://linux-ima.sourceforge.net/

Es ist noch nicht unterzeichnen, aber es ermöglicht noch Verifikation.

ich die Frage von einem Solaris 10 & 11 OS Perspektive beantworten kann, werden alle Binärdateien unterzeichnet. Um zu überprüfen, die Unterschrift Verwendung '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 vor kurzem einen überprüfte Boot-Prozess für Solaris 11 auch hinzugefügt, für Details siehe - Solaris Verified Boot Einführung

Es gibt einige Produktionserz Gabeln des Opensolaris-Code, drei Untersuchung wert sind Illumos, SmartOS und OmniOS.

Hier finden Sie aktuelle Medusa DS9 . Ich spielte mit ihm eine lange ( lang ) Zeit her, aber wenn ich mich richtig erinnere, können Sie bestimmen Binärdateien registrieren und jede Änderung wurde nicht auf Kernel-Ebene erlaubt. Natürlich kann es mit dem lokalen Zugriff auf die Maschine außer Kraft gesetzt werden, aber es war nicht einfach. Es gibt einen Smart-Dämon namens Constable, alles überprüft, die auf der Maschine passiert, und wenn etwas aus dem üblichen heraus auftritt, beginnen zu schreien.

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

Verwenden Sie ein PKCS7 (S / MIME) Zeichen davon. Generieren Sie Ihre eigenen cert / privates Schlüsselpaar, selbst unterzeichnen das CERT und melden Sie Ihre Datei mit dem privaten Schlüssel und cert PKCS7 verwenden. Es wird das CERT es, befestigen und dann kann es sich zur Laufzeit überprüfen Sie die OpenSSL-Befehl (Mann smime oder einfach nur tun OpenSSL-Hilfe). Dies ist manipulationssicher, denn auch wenn der öffentliche Schlüssel in den Dateien, die Sie geben, kann die S / MIME-Signatur für den öffentlichen Schlüssel nur mit dem privaten Schlüssel erzeugt werden, die Sie nicht verteilen. Also, wenn die Datei von Ihrem cert signiert ist, es von jemandem mit dem privaten Schlüssel signiert sein müssen und da Sie nicht den privaten Schlüssel zu jedermann gegeben haben, muss er von euch kommen.

Hier ist, wie das selbst signierte Zertifikat zu machen.

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

Sie werden openssl überzeugen, dass Ihr Zertifikat als eine Wurzel der Autorität zu vertrauen (-CAfile), dann überprüfen Sie es mit, dass als die Wurzel, und überprüfen Sie auch die cert auf die Datei liegt bei Ihnen (hash das CERT) und Scheck die Hash. Beachten Sie, dass, obwohl es nicht dokumentiert ist, spiegelt der Exit-Status von OpenSSL die Gültigkeit des Zeichens Sie überprüft werden, wenn ein smime überprüfen zu tun. Es ist 0, wenn sie paßt, nicht-Null, wenn es nicht.

Beachten Sie, dass all dies ist nicht sicher, weil, wenn die Überprüfung im Code ist, können sie einfach den Scheck entfernen, wenn sie möchten, dass Sie schlagen. Der einzige sichere Weg, es zu tun wäre, um die Prüfer in dem O zu haben und hat es Ihre Binär- und Müll zu überprüfen, um sie auszuführen, wenn es nicht unterzeichnet ist. Aber da gibt es keinen Stein in dem O und Linux ist modifiziert werden kann, entfernen / Bypass es trotzdem ... Was dies für wirklich gut ist, ist nur Erkennung beschädigte Dateien mehr als zu versuchen, die Menschen zu halten, von Ihnen zu umgehen.

Ich bin damit einverstanden, dass die Philosophie Linux Umgebung, GNU et al. dreht sich um bastelt. Auf der anderen Seite, ich glaube auch, dass einige Systeme verdienen Schutz vor Schwachstellen wie zB Software-Manipulation, die die Privatsphäre und Integrität eines Systems Nutzer untergraben kann.

Kernel-Implementierungen können nicht mit dem schnellen Entwicklungszyklus des Kernels selbst halten. Ich empfehle stattdessen Überprüfung mit Anwendungstools eine Form von ausführbaren Dateisignatur zu implementieren. Platz ausführbare Dateien in einem Archiv oder Dateisystem-Image und unterschreiben Sie das Bild mit einem privaten Schlüssel; wenn dass private Schlüssel bleibt auf dem Entwicklungsmaschinen (privat), wenn der Server gehackt wird, haben Angreifer noch keine Möglichkeit, ihre eigenen Bilder zu unterzeichnen und ihren Code zu injizieren, ohne das System austricksen unsigned Bilder zu montieren. Es erstreckt sich weiter entlang der Kette:

  • haben Ihre Dienste enthalten in Runtime-les- nur Bilder;
  • hat die Maschine von einem unterzeichneten ablaufen, read-only-Dateisystem;
  • implementieren sicheres Boot auf Ihrem Rechner, einen Bootloader ausgeführt wird, der die Integrität des Bootmediums erzwingt;
  • Vertrauen, dass die Menschen in Ihrer Organisation nicht manipulations mit Ihren Maschinen.

alles richtig hinzubekommen ist ein hartes Unterfangen. Es ist viel einfacher zu arbeiten um sie alle von Ihrem System unter einem anderen Ansatz der Gestaltung:

  • Quarantäne Benutzer aus dem System. Nicht mit Mitteln für die Benutzer Befehle auf dem System auszuführen. Vermeiden Sie Beschuss aus aus dem Inneren der Programme, die auf Benutzer-fed Daten verlassen.
  • entwerfen Sie Ihre Bereitstellungsverfahren Konfigurationsmanagement mit und stellen Sie sicher, dass Ihre Einsätze sind „wiederholbar“, was bedeutet, dass sie auf das gleiche funktionelle Ergebnis führen, wenn man sie mehrmals bereitstellen. Dies ermöglicht es Ihnen, „Nuke aus dem Orbit“ -Maschinen, dass Sie vermuten, kompromittiert wurden.
  • behandeln Ihre Maschinen, als ob sie kompromittiert wurden: regelmäßig laufen Audits die Integrität Ihrer Systeme zu überprüfen. Speichern Sie Ihre Daten auf getrennten Bildern und redeploy Systeme regelmäßig. Melden Sie Bilder und haben Systeme ablehnen unsigned Bilder.
  • Ausweisungs: favorisieren eine „-Zertifikat Pinning“ -Ansatz. Haben deploy ein Stammzertifikat für Ihre Anwendungen (die automatische Ablehnung von Signaturen bieten wird, die nicht von der Organisation zertifiziert), aber zumindest haben das System verwalten Fingerabdrücke von aktuellen Bildern und benachrichtigt den Administrator, wenn Fingerabdrücke geändert haben. Obwohl es möglich ist, alle diese mit Ketten des Schlüssels zu implementieren, zertifikatsbasierte Authentifizierung für diese genaue Anwendung entwickelt wurde.

Ich mag als eine Kette mit Sicherheit denken. Das schwächere Glied der Kette kann das ganze System gefährden. Also das Ganze geworden „ ein nicht autorisierter Benutzer Erhalt des Root-Passwort verhindert “.

Wie bereits angedeutet durch die Quelle der Software @DanMoulding ist auch wichtig, und in der Zukunft wahrscheinlich offizielle OS-Anwendung speichert wird der Standard sein. Spielen Sie darüber nachdenken, Store, Apple oder Microsoft speichert.

  

ich denke, Installation und Verteilung von verdeckten bösartigem Code ist die   weit heimtückisches Problem. Schließlich, um schlechten Code zu laden, es ist   bekommen zunächst auf dem System irgendwo installiert werden. Weitere Schichten   Sicherheit ist in der Regel besser, natürlich. Die Frage ist: ist es wert   die Kosten?

Meiner Meinung nach ist die Antwort „es kommt“. Sie können durch die Annahme einer Reihe von Sicherheitsrichtlinien das Risiko verringern, wie durch @sleblanc vorgeschlagen. Sie können Ihr Dateisystem ( https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup verschlüsseln ), die Verwendung schreibgeschützte Dateisysteme für die Binärdateien oder einen Mechanismus verwenden, um die Binärdateien zu unterzeichnen und überprüfen.

Doch was Mechanismus Sie es verwenden, ist nichts, was man tun kann, wenn der Root-Zugriff von einem Angreifer erhalten wird. Die Signaturprüfung Werkzeuge können mit einer manipulierten Version ersetzt werden oder nur deaktiviert, und es ist nicht wirklich wichtig, wenn die Werkzeuge in User-Space oder Kernel-Space laufen einmal, dass die Maschine (obwohl letztere sicherer wäre natürlich beeinträchtigt wurde ).

So ist es schön wäre, wenn die Linux-Kernel könnte eine Signaturprüfung Modul und eine weitere Sicherheitsschicht zwischen dem Root-Benutzer einbettet und dem Betriebssystem.

Zum Beispiel ist dies der Ansatz auf der letzten angenommenen macOS Versionen. Einige Datei kann nicht geändert werden (und manchmal lesen) auch durch den Root-Account und es gibt Einschränkungen auch auf die Politik und die Kernel-Module (z nur signiert oder autorisierte kext können auf das System geladen werden). Fenster mehr oder weniger den gleichen Ansatz mit AppLocker .

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top