L'azienda ha presentato alla mailing list degli sviluppatori del kernel Linux il codice del modulo LSM che implementa il meccanismo IPE (Integrity Policy Enforcement), il quale espande i sistemi esistenti di controllo degli accessi basati su mandato. Invece di essere legato a etichette e percorsi, in IPE la decisione di autorizzare o negare 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 consentite e in che modo dovrebbe essere verificata l'autenticità dei componenti.
IPE mira a creare sistemi completamente verificabili, la cui integrità è confermata dal bootloader iniziale e dal kernel fino ai file eseguibili finali, alle configurazioni e ai file caricati. Ad esempio, grazie a IPE è possibile specificare quali file eseguibili possono essere eseguiti, tenendo conto della verifica della loro corrispondenza con la versione di riferimento utilizzando 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 di una violazione dell'integrità.
Il meccanismo proposto può essere utilizzato nei firmware per dispositivi embedded, dove tutto il software e le impostazioni sono specificamente raccolti e forniti dal proprietario. Ad esempio, nei data center Microsoft, IPE è applicato all'hardware per i firewall. A differenza di altri sistemi di verifica dell'integrità, come IMA, IPE è indipendente dai metadati nel file system: tutte le proprietà che definiscono la validità delle operazioni sono memorizzate direttamente nel kernel.
Le regole sono definite in forma testuale utilizzando insiemi chiave-valore. Le chiavi di base includono 'op', che definisce l'operazione a cui si applica la regola (ad esempio, op=EXECUTE attiverà l'azione quando viene effettuato un tentativo di esecuzione), e 'action', che determina 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 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 boot da una partizione verificata, negheranno l'esecuzione di file da partizioni prive di firme in dm-verity e, inoltre, bloccheranno selettivamente l'esecuzione di un file con l'hash '401fce…0dec146938'.
L'insieme iniziale delle regole di boot è definito tramite la configurazione SECURITY_IPE_BOOT_POLICY e viene incluso nella build del kernel, mentre le ulteriori regole possono essere aggiunte secondo necessità attraverso il file /sys/kernel/security/ipe/new_policy. Le regole trasmesse sono criptate utilizzando un certificato definito in SYSTEM_TRUSTED_KEYRING.
Nei sistemi di uso generale, si propone di applicare IPE in combinazione con il meccanismo DIGLIM, sviluppato da Huawei. DIGLIM è implementato utilizzando eBPF e consente di realizzare facilmente un controllo dell'integrità a livello di file singoli in normali distribuzioni, senza richiederne una riqualificazione (presentato come un'alternativa a Secure Boot, operante a livello applicativo). L'essenza di DIGLIM è mantenere un pool di hash di verifica per file e metadati, e fornire accesso ai file eseguibili solo se il loro hash è presente nel pool. L'elenco degli hash può essere ottenuto dal gestore di pacchetti RPM o generato manualmente dall'utente.
Fonte: opennet.ru
