L'azienda ha presentato in discussione nella mailing list degli sviluppatori del kernel Linux il codice del modulo LSM con l'implementazione del meccanismo IPE (Integrity Policy Enforcement), che estende i sistemi esistenti di gestione degli accessi obbligatoria. Invece di essere legato a etichette e percorsi, in IPE la decisione di consentire o vietare un'operazione viene presa sulla base delle proprietà permanenti del componente di sistema con cui viene eseguita l'operazione. Il modulo consente di definire una politica generale di integrità per l'intero sistema, indicando quali operazioni sono ammissibili e come verificare l'autenticità dei componenti.
IPE mira a creare sistemi completamente verificabili, la cui integrità è confermata dal boot loader iniziale e dal kernel fino ai file eseguibili finali, alle configurazioni e ai file caricati. Ad esempio, tramite IPE è possibile specificare quali file eseguibili possono essere eseguiti, tenendo conto della verifica della loro corrispondenza con la versione di riferimento tramite gli hash crittografici forniti dal sistema dm-verity. In caso di modifica o sostituzione di un file, IPE può bloccare l'operazione o registrare il fatto della violazione dell'integrità.
Il meccanismo proposto può essere utilizzato nei firmware per dispositivi embedded, in cui tutto il software e le impostazioni sono appositamente raccolti e forniti dal proprietario; ad esempio, nei data center Microsoft IPE è utilizzato nell'hardware dei firewall. Diversamente da altri sistemi di verifica dell'integrità, come IMA, IPE si distingue per l'indipendenza dai metadati nel FS: tutte le proprietà che determinano l'ammissibilità delle operazioni sono memorizzate direttamente nel kernel.
Le regole sono definite in forma testuale utilizzando insiemi chiave-valore. Le chiavi fondamentali sono "op", che definisce l'operazione a cui si applica la regola (ad esempio, op=EXECUTE verrà attivato nel tentativo di esecuzione), e "action", che definisce l'azione (ad esempio, "action=DENY" per bloccare). Le regole sono legate alle proprietà fornite da sottosistemi esterni come dm-verity e fs-verity.
Ad esempio, le regole di avvio op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY consentiranno solo il caricamento da una partizione verificata, impediranno l'esecuzione di file da partizioni prive di firme in dm-verity e selettivamente bloccheranno l'esecuzione di file con l'hash «401fce…0dec146938».
L'insieme iniziale delle regole di avvio è definito tramite la configurazione SECURITY_IPE_BOOT_POLICY ed è incluso nella compilazione del kernel, mentre le ulteriori regole vengono aggiunte secondo necessità tramite il file /sys/kernel/security/ipe/new_policy. Le regole trasmesse sono crittografate utilizzando un certificato specificato nel SYSTEM_TRUSTED_KEYRING.
Nei sistemi di uso generale, si suggerisce di applicare IPE in combinazione con il meccanismo DIGLIM, sviluppato da Huawei. DIGLIM è implementato tramite eBPF e consente di realizzare facilmente il controllo dell'integrità a livello di singoli file nelle distribuzioni standard, senza richiedere una loro riprogettazione (presentato come una variante di Secure Boot operante a livello applicativo). Il concetto di DIGLIM consiste nel mantenere un pool di hash di controllo per file e metadati, e fornire accesso a file eseguibili solo se il loro hash è presente nel pool. L'elenco degli hash può essere ottenuto dal gestore pacchetti RPM o generato manualmente dall'utente.
Fonte: opennet.ru
