L'azienda ha pubblicato la questione sulla mailing list degli sviluppatori del kernel per avviarne la discussione. Linux Il codice del modulo LSM implementa il meccanismo IPE (Integrity Policy Enforcement), estendendo i sistemi di controllo degli accessi obbligatori esistenti. Invece di basarsi su etichette e percorsi, IPE consente di autorizzare o negare le operazioni in base alle proprietà costanti del componente di sistema su cui si interviene. Il modulo permette di definire una politica di integrità generale per l'intero sistema, specificando quali operazioni sono consentite e come deve essere verificata l'autenticità dei componenti.
L'obiettivo di IPE è creare sistemi completamente verificabili, la cui integrità è confermata dal bootloader e dal kernel fino agli eseguibili finali, alla configurazione e ai file caricabili. Ad esempio, IPE può essere utilizzato per specificare quali eseguibili possono essere eseguiti, in base alla loro conformità con la versione di riferimento, utilizzando hash crittografici forniti dal sistema dm-verity. Se un file viene modificato o manomesso, IPE può bloccare l'operazione o registrare la violazione di integrità.
Il meccanismo proposto può essere utilizzato nel firmware per dispositivi embedded, in cui tutto il software e le impostazioni sono compilati e forniti specificamente dal proprietario. Ad esempio, nei data center Microsoft, IPE viene utilizzato nelle apparecchiature firewall. A differenza di altri sistemi di controllo dell'integrità, come IMA, IPE è indipendente dai metadati del file system: tutte le proprietà che determinano l'ammissibilità delle operazioni sono memorizzate direttamente nel kernel.
Le regole sono definite in formato testo utilizzando insiemi chiave-valore. Le chiavi di base sono "op", che definisce l'operazione a cui si applica la regola (ad esempio, op=EXECUTE attiverà un tentativo di esecuzione), e "action", che definisce l'azione (ad esempio, "action=DENY" per il blocco). Le regole sono vincolate alle proprietà fornite da sottosistemi esterni come dm-verity e fs-verity.
Ad esempio, le regole op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY consentiranno l'avvio solo da una partizione verificata, impediranno l'esecuzione di file da partizioni che non hanno firme in dm-verity e impediranno anche selettivamente l'esecuzione di un file con hash "401fce…0dec146938".
Il set iniziale di regole di avvio viene definito utilizzando l'impostazione SECURITY_IPE_BOOT_POLICY e incluso nella build del kernel, mentre altre regole vengono aggiunte in base alle esigenze tramite il file /sys/kernel/security/ipe/new_policy. Le regole passate vengono crittografate utilizzando il certificato specificato in SYSTEM_TRUSTED_KEYRING.
Per i sistemi generici, si consiglia di utilizzare IPE in combinazione con il meccanismo DIGLIM sviluppato da Huawei. DIGLIM è implementato tramite eBPF e consente una facile implementazione del controllo di integrità a livello di file nelle distribuzioni standard senza richiedere modifiche (viene presentato come una variante di Secure Boot che opera a livello applicativo). DIGLIM gestisce un pool di hash di verifica per file e metadati e concede l'accesso ai file eseguibili solo se il relativo hash è presente nel pool. L'elenco degli hash può essere ottenuto dal gestore di pacchetti RPM o generato manualmente dall'utente.
Fonte: opennet.ru
