Das Unternehmen hat einen LSM-Modulcode zur Diskussion in der Mailingliste für Linux-Kernel-Entwickler vorgeschlagen, der einen IPE-Mechanismus (Integrity Policy Enforcement) implementiert. Dieser erweitert bestehende Systeme des Mandatssystems zur Zugriffskontrolle. Anstelle von Bindungen an Labels und Pfade werden im IPE Entscheidungen zur Genehmigung oder Verweigerung von Operationen basierend auf den konstanten Eigenschaften der Systemkomponente getroffen, mit der die Operation ausgeführt wird. Das Modul ermöglicht es, eine allgemeine Integritätsrichtlinie für das gesamte System zu definieren, die angibt, welche Operationen zulässig sind und wie die Authentizität der Komponenten überprüft werden sollte.
IPE zielt darauf ab, vollständig verifizierbare Systeme zu schaffen, deren Integrität von dem ursprünglichen Bootloader und dem Kern bis hin zu den endgültigen ausführbaren Dateien, Konfigurationen und geladenen Dateien bestätigt wird. Beispielsweise kann mit IPE angegeben werden, welche ausführbaren Dateien unter Berücksichtigung ihrer Übereinstimmung mit der Referenzversion durch kryptographische Hashes, die vom System dm-verity bereitgestellt werden, ausgeführt werden dürfen. Im Falle einer Änderung oder Manipulation der Datei kann IPE die Operation blockieren oder den Verstoß gegen die Integrität protokollieren.
Der vorgeschlagene Mechanismus kann in Firmware für eingebettete Geräte angewendet werden, bei denen die gesamte Software und die Einstellungen speziell vom Eigentümer gesammelt und bereitgestellt werden. Zum Beispiel wird IPE in den Microsoft-Rechenzentren in der Hardware für Firewalls verwendet. Im Gegensatz 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.
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 funktioniert op=EXECUTE bei einem Ausführungsversuch), und "action", die die Aktion definiert (zum Beispiel "action=DENY" zum Blockieren). Regelsysteme werden an Eigenschaften gebunden, die von externen Subsystemen wie dm-verity und fs-verity bereitgestellt werden.
Beispielsweise 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 einem verifizierten Bereich, untersagen die Ausführung von Dateien aus Bereichen ohne Signaturen in dm-verity und verbieten selektiv die Ausführung einer Datei mit dem Hash „401fce…0dec146938“.
Der anfängliche Satz von Boot-Regeln wird durch die Einstellung SECURITY_IPE_BOOT_POLICY festgelegt und ist Bestandteil des Kernel-Bau, während andere Regeln bei Bedarf über die Datei /sys/kernel/security/ipe/new_policy hinzugefügt werden. Die übermittelten Regeln werden unter Verwendung eines in SYSTEM_TRUSTED_KEYRING festgelegten Zertifikats verschlüsselt.
Auf allgemeinen Systemen wird empfohlen, IPE zusammen mit dem von Huawei entwickelten DIGLIM-Mechanismus anzuwenden. DIGLIM wird über eBPF implementiert und ermöglicht eine einfache Integritätskontrolle auf Dateiebene in gängigen Distributionen, ohne dass diese überarbeitet werden müssen (es wird als eine Variante von Secure Boot präsentiert, die auf Anwendungsebene funktioniert). Die Idee von DIGLIM besteht darin, einen Pool von Prüfziffern für Dateien und Metadaten aufrechtzuerhalten und den Zugriff auf ausführbare Dateien nur zu gewähren, wenn ihre Prüfziffer im Pool enthalten ist. Die Liste der Prüfziffern kann vom RPM-Paketmanager bezogen oder manuell vom Benutzer generiert werden.
Quelle: opennet.ru
