A empresa apresentou à discussão na lista de e-mails dos desenvolvedores do núcleo do Linux o código do módulo LSM com a implementação do mecanismo IPE (Integrity Policy Enforcement), que amplia os sistemas existentes de controle de acesso mandatório. Em vez de estar vinculado a rótulos e caminhos, no IPE a decisão de permitir ou proibir uma operação é tomada com base em propriedades permanentes do componente do sistema com o qual a operação é realizada. O módulo permite definir uma política geral de integridade para todo o sistema, indicando quais operações são permitidas e de que maneira a autenticidade dos componentes deve ser verificada.
O IPE visa criar sistemas totalmente verificáveis, cuja integridade é confirmada desde o carregador inicial e o núcleo até os arquivos executáveis finais, configurações e arquivos carregados. Por exemplo, através do IPE é possível indicar quais arquivos executáveis podem ser iniciados, levando em conta a verificação da conformidade com a versão de referência usando hashes criptográficos fornecidos pelo sistema dm-verity. Em caso de alteração ou substituição de um arquivo, o IPE pode bloquear a operação ou registrar a violação da integridade.
O mecanismo proposto pode ser aplicado em firmwares para dispositivos embutidos, nos quais todo o software e as configurações são especificamente coletados e fornecidos pelo proprietário; por exemplo, em data centers da Microsoft, o IPE é aplicado em equipamentos de firewalls. Diferente de outros sistemas de verificação de integridade, como o IMA, o IPE se distingue pela independência dos metadados no FS — todas as propriedades que determinam a permissibilidade das operações estão armazenadas diretamente no núcleo.
As regras são definidas em forma de texto utilizando conjuntos de chave-valor. As chaves básicas são "op", que define a operação à qual a regra se aplica (por exemplo, op=EXECUTE será ativada em uma tentativa de execução), e "action", que determina a ação (por exemplo, "action=DENY" para bloqueio). As regras estão vinculadas a propriedades fornecidas por subsistemas externos, como dm-verity e fs-verity.
Por exemplo, as regras op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY permitirão apenas o carregamento a partir de uma partição verificada, proibindo a execução de arquivos de partições que não têm assinaturas em dm-verity, além de bloquear seletivamente a execução do arquivo com o hash "401fce…0dec146938".
O conjunto inicial de regras de inicialização é definido através da configuração SECURITY_IPE_BOOT_POLICY e faz parte da compilação do núcleo, enquanto outras regras são adicionadas conforme necessário através do arquivo /sys/kernel/security/ipe/new_policy. As regras transmitidas são criptografadas usando um certificado definido em SYSTEM_TRUSTED_KEYRING.
Em sistemas de uso geral, recomenda-se aplicar o IPE em conjunto com o mecanismo DIGLIM, desenvolvido pela Huawei. O DIGLIM é implementado usando eBPF e permite facilitar o controle de integridade no nível de arquivos individuais em distribuições comuns, sem exigir sua reformulação (apresentado como uma versão do Secure Boot que opera em nível de aplicação). A essência do DIGLIM é manter um pool de hashes de verificação para arquivos e metadados, fornecendo acesso a arquivos executáveis somente se seu hash estiver presente no pool. A lista de hashes pode ser obtida do gerenciador de pacotes RPM ou gerada manualmente pelo usuário.
Fonte: opennet.ru
