Das Unternehmen hat im Entwickler-Newsletter des Linux-Kernels den Code eines LSM-Moduls zur Implementierung des IPE-Mechanismus (Integrity Policy Enforcement) zur Diskussion gestellt, der bestehende Systeme der mandatorischen Zugriffskontrolle erweitert. Anstelle von Labeln und Pfaden wird im IPE die Entscheidung über die Erlaubnis oder Verweigerung einer Operation basierend auf konstanten Eigenschaften der Systemkomponente getroffen, mit der die Operation ausgeführt wird. Das Modul ermöglicht die Festlegung einer allgemeinen Integritätspolitik für das gesamte System, die angibt, welche Operationen zulässig sind und wie die Authentizität der Komponenten verifiziert werden sollte.
IPE zielt darauf ab, vollständig verifizierbare Systeme zu schaffen, deren Integrität von dem ursprünglichen Bootloader und Kernel bis hin zu den endgültigen ausführbaren Dateien, Konfigurationen und geladenen Dateien bestätigt wird. Zum Beispiel kann mit IPE festgelegt werden, welche ausführbaren Dateien unter Berücksichtigung der Überprüfung ihrer Übereinstimmung mit der Referenzversion mithilfe der kryptografischen Hashes, die vom System dm-verity bereitgestellt werden, gestartet werden dürfen. Im Falle einer Änderung oder Ersetzung einer Datei kann IPE die Operation blockieren oder das Ereignis eines Integritätsbruchs protokollieren.
Der vorgeschlagene Mechanismus kann in Firmware für eingebettete Geräte angewendet werden, bei denen alle Software und Einstellungen speziell vom Eigentümer zusammengestellt und bereitgestellt werden. Beispielsweise wird IPE in Microsoft-Datenzentren in der Hardware für Firewalls eingesetzt. Im Unterschied zu anderen Integritätsprüfsystemen wie IMA zeichnet sich IPE durch die Unabhängigkeit von Metadaten im Dateisystem aus – alle Eigenschaften, die die Zulässigkeit von Operationen bestimmen, werden direkt im Kernel gespeichert.
Die Regeln werden in Textform unter Verwendung von Schlüssel-Wert-Paaren festgelegt. Die grundlegenden Schlüssel sind „op“, der die Operation definiert, auf die die Regel angewendet wird (zum Beispiel wird op=EXECUTE bei dem Versuch, eine Datei auszuführen, aktiviert), und „action“, der die Handlung definiert (zum Beispiel „action=DENY“ zum Blockieren). Regeln werden an Eigenschaften gebunden, die von externen Subsystemen wie dm-verity und fs-verity bereitgestellt werden.
Zum Beispiel erlauben die Regeln op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY nur das Booten von verifiziertem Speicher, blockieren die Ausführung von Dateien aus nicht signierten Partitionen in dm-verity und verbieten selektiv die Ausführung einer Datei mit dem Hash „401fce…0dec146938“.
Das Ausgangsset von Boot-Regeln wird mithilfe der Einstellung SECURITY_IPE_BOOT_POLICY definiert und ist Teil des Kernel-Builds, während weitere Regeln bei Bedarf über die Datei /sys/kernel/security/ipe/new_policy hinzugefügt werden. Die übermittelten Regeln werden mithilfe eines in SYSTEM_TRUSTED_KEYRING definierten Zertifikats verschlüsselt.
In allgemeinen Systemen wird empfohlen, IPE in Verbindung mit dem von Huawei entwickelten DIGLIM-Mechanismus anzuwenden. DIGLIM wird mithilfe von eBPF implementiert und ermöglicht die einfache Durchsetzung der Integrität auf der Ebene einzelner Dateien in gängigen Distributionen, ohne dass Änderungen erforderlich sind (es wird als eine Art Secure Boot beschrieben, das auf Anwendungsebene arbeitet). Das Wesen von DIGLIM besteht darin, einen Pool von Prüfziffern für Dateien und Metadaten zu führen und den Zugriff auf ausführbare Dateien nur zu gewähren, wenn deren Hash im Pool vorhanden ist. Die Liste der Hashes kann vom RPM-Paketmanager abgerufen oder manuell vom Benutzer generiert werden.
Quelle: opennet.ru
