La empresa ha puesto a discusión en la lista de correo de los desarrolladores del núcleo de Linux el código del módulo LSM con la implementación del mecanismo IPE (Integrity Policy Enforcement), que extiende los sistemas existentes de control de acceso mandatarios. En lugar de estar vinculado a etiquetas y rutas, en IPE la decisión de permitir o prohibir una operación se basa en las propiedades permanentes del componente del sistema con el que se lleva a cabo la operación. El módulo permite definir una política general de aseguramiento de la integridad para todo el sistema, que indica qué operaciones son permitidas y cómo se debe verificar la autenticidad de los componentes.
IPE está diseñado para crear sistemas completamente verificables, cuya integridad se confirma desde el cargador inicial y el núcleo hasta los archivos ejecutables finales, configuraciones y archivos cargados. Por ejemplo, mediante IPE se puede especificar qué archivos ejecutables se pueden lanzar considerando la verificación de su correspondencia con la versión de referencia mediante los hashes criptográficos proporcionados por el sistema dm-verity. En caso de que un archivo sea modificado o reemplazado, IPE puede bloquear la operación o registrar el hecho de la violación de la integridad.
El mecanismo propuesto puede aplicarse en firmware para dispositivos embebidos, donde todo el software y la configuración son especialmente compilados y proporcionados por el propietario; por ejemplo, en los centros de datos de Microsoft, IPE se utiliza en el hardware para cortafuegos. A diferencia de otros sistemas de verificación de integridad, como IMA, IPE se distingue por su independencia de los metadatos en el FS: todas las propiedades que determinan la permisibilidad de las operaciones se almacenan directamente en el núcleo.
Las reglas se definen en forma de texto utilizando conjuntos clave-valor. Las clave básicas son "op", que determina la operación a la que se aplica la regla (por ejemplo, op=EXECUTE se activará al intentar ejecutar), y "action", que determina la acción (por ejemplo, "action=DENY" para bloquear). Las reglas se conectan a las propiedades proporcionadas por subsistemas externos, como dm-verity y fs-verity.
Por ejemplo, las reglas op=EXECUTE boot_verified=TRUE action=ALLOW op=EXECUTE dmverity_signature=FALSE action=DENY op=EXECUTE fsverity_digest=sha256:401fce…0dec146938 action=DENY permitirán solo el arranque desde la partición verificada, prohibirán la ejecución de archivos desde particiones que no tienen firmas en dm-verity, y también prohibirán selectivamente la ejecución del archivo con el hash «401fce…0dec146938».
El conjunto inicial de reglas de arranque se determina mediante la configuración SECURITY_IPE_BOOT_POLICY y se incluye en la compilación del kernel, mientras que las demás reglas se añaden según sea necesario a través del archivo /sys/kernel/security/ipe/new_policy. Las reglas transmitidas se cifran utilizando un certificado definido en SYSTEM_TRUSTED_KEYRING.
En sistemas de propósito general, se sugiere aplicar IPE en combinación con el mecanismo DIGLIM, desarrollado por Huawei. DIGLIM se implementa mediante eBPF y permite implementar fácilmente el control de integridad a nivel de archivos individuales en distribuciones comunes, sin necesidad de reworking (se presenta como una variante de Secure Boot que opera a nivel de aplicación). La esencia de DIGLIM es mantener un conjunto de hashes de verificación para archivos y metadatos, y proporcionar acceso a archivos ejecutables solo si su hash está presente en el conjunto. La lista de hashes puede obtenerse del gestor de paquetes RPM o ser generada manualmente por el usuario.
Fuente: opennet.ru
