Signierte ausführbare Dateien unter Linux

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

Ich habe vor einiger Zeit eine Unterstützung für signierte ausführbare Dateien für den Linux-Kernel (etwa Version 2.4.3) geschrieben und hatte die gesamte Toolchain zum Signieren von ausführbaren Dateien vorhanden, wobei ich die Signaturen bei execve(2) überprüfte Zeit, Zwischenspeichern der Signatur-Validierungsinformationen (Löschen der Validierung, wenn die Datei zum Schreiben geöffnet oder anderweitig geändert wurde), Einbetten der Signaturen in beliebige ELF-Programme usw. Es führte einige Leistungseinbußen bei der ersten Ausführung jedes Programms ein (weil der Kernel musste gesamt geladen werden Datei, anstatt nur die benötigten Seiten anzufordern), aber sobald das System in einem stabilen Zustand war, funktionierte es gut.

Aber wir haben uns entschieden, es nicht weiter zu verfolgen, weil es mit mehreren Problemen konfrontiert war, die zu groß waren, um die Komplexität zu rechtfertigen:

• Wir hatten noch keine Unterstützung für signierte Bibliotheken eingebaut . Signierte Bibliotheken müssten auch ld.so ändern Lader und die dlopen(3) Mechanismus. Das war nicht unmöglich, verkomplizierte aber die Schnittstelle:Soll der Loader den Kernel auffordern, eine Signatur zu validieren, oder sollte die Berechnung vollständig im Userspace erfolgen? Wie würde man sich vor einer strace(2) schützen d Prozess, wenn dieser Teil der Validierung im Userspace erfolgt? Wären wir gezwungen, strace(2) zu verbieten? ausschließlich auf einem solchen System?

  Was würden wir mit Programmen machen, die ihren eigenen Loader bereitstellen?

• Sehr viele Programme sind in Sprachen geschrieben, die nicht zu ELF-Objekten kompiliert werden. Wir müssten sprachspezifisch angeben Änderungen an bash , perl , python , java , awk , sed , und so weiter, damit jeder der Interpreter auch kann Signaturen validieren. Da die meisten dieser Programme frei formatierter Klartext sind, fehlt ihnen die Struktur, die das Einbetten digitaler Signaturen in ELF-Objektdateien so einfach gemacht hat. Wo würden die Signaturen gespeichert? In den Skripten? In erweiterten Attributen? In einer externen Signaturdatenbank?

• Viele Dolmetscher sind offen darüber, was sie erlauben; bash(1) kann ganz alleine mit entfernten Systemen kommunizieren mit echo und /dev/tcp , und kann leicht dazu verleitet werden, alles auszuführen, was ein Angreifer tun muss. Signiert oder nicht, man konnte ihnen nicht mehr vertrauen, sobald sie einmal unter der Kontrolle eines Hackers waren.

• Die Hauptmotivation für die Unterstützung signierter ausführbarer Dateien kommt von Rootkits, die den vom System bereitgestellten /bin/ps ersetzen , /bin/ps , /bin/kill , usw. Ja, es gibt noch andere nützliche Gründe für signierte ausführbare Dateien. Rootkits wurden jedoch im Laufe der Zeit deutlich beeindruckender, wobei sich viele auf Kernel stützten Hacks, um ihre Aktivitäten vor Administratoren zu verbergen. Sobald der Kernel gehackt wurde, ist das ganze Spiel vorbei. Aufgrund der Komplexität von Rootkits gerieten die Tools, die wir zu verhindern hofften, in der Hacker-Community in Ungnade.

• Die Schnittstelle zum Laden von Modulen des Kernels war weit offen. Sobald ein Prozess root hat Privileg war es einfach, ein Kernelmodul ohne Prüfung einzufügen. Wir hätten auch einen anderen Prüfer für Kernel-Module schreiben können, aber die Infrastruktur des Kernels um Module herum war sehr primitiv.

Das GNU/Linux/FOSS-Modell ermutigt tatsächlich zu Manipulationen – in gewisser Weise. Benutzern und Distributionsherstellern muss es freistehen, die Software an ihre Bedürfnisse anzupassen (zu manipulieren). Auch das bloße Neukompilieren der Software (ohne Änderung des Quellcodes) zur Anpassung wird häufig durchgeführt, würde aber die binäre Code-Signierung beeinträchtigen. Daher ist das binäre Code-Signing-Modell nicht besonders gut für GNU/Linux/FOSS geeignet.

Stattdessen verlässt sich diese Art von Software mehr auf die Generierung von Signaturen und/oder sicheren Hashes der Quellpakete. In Kombination mit einem zuverlässigen und vertrauenswürdigen Paketverteilungsmodell kann dies genauso sicher gemacht werden (wenn nicht sogar noch sicherer in Bezug auf die Transparenz des Quellcodes) wie die binäre Code-Signierung.

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

Schau mal hier:http://linux-ima.sourceforge.net/

Es signiert noch nicht, aktiviert aber dennoch die Verifizierung.