Estoy perfilando algún software propietario para construir un conjunto de requisitos de permisos y políticas de SELinux para permitir su instalación y ejecución en Oracle Linux (o cualquier derivado de RHEL).
Estoy ejecutando SELinux en modo permisivo, ejecuté semodule -DB para deshabilitar "dontaudit" y estoy viendo /var/log/audit/audit.log para ver los resultados.
Sin embargo, me gustaría ver también TODO lo que se permitió (no solo las denegaciones o las auditorías), que parecen ser la mayoría a juzgar por esto:
[root@aw-selinuxtest ~]# seinfo --stats
Statistics for policy file: /etc/selinux/targeted/policy/policy.24
Policy Version & Type: v.24 (binary, mls)
Classes: 81 Permissions: 237
Sensitivities: 1 Categories: 1024
Types: 3852 Attributes: 291
Users: 9 Roles: 12
Booleans: 228 Cond. Expr.: 268
Allow: 311381 Neverallow: 0
Auditallow: 133 Dontaudit: 0
Type_trans: 38576 Type_change: 38
Type_member: 48 Role allow: 19
Role_trans: 368 Range_trans: 5601
Constraints: 90 Validatetrans: 0
Initial SIDs: 27 Fs_use: 24
Genfscon: 84 Portcon: 471
Netifcon: 0 Nodecon: 0
Permissives: 91 Polcap: 2
¿Alguien sabe como hacer esto? Estoy luchando por encontrar una respuesta hasta ahora.
Respuesta1
Contrariamente a la práctica habitual, configurar SELinux en permissivemodo y registrar todas las denegaciones de AVC para desarrollar un módulo de políticas puede dar como resultado que se incluya un conjunto incorrecto de permisos en dicha política.
Un ejemplo de esto podría ser el siguiente: supongamos que el funcionamiento normal de este software propietario requiere de untransición de dominio, en modo permisivo, la transición no ocurre y parece que el dominio de origen requiere todos los permisos registrados como denegaciones AVC (Libro de cocina SELinux de Sven Vermeulencontiene varias referencias a este posible problema).
Un mejor enfoque para crear un módulo de políticas para un software propietario sería mantener SELinux en modo de cumplimiento en primer lugar, para garantizar laprivilegios mínimosposible.
Lo siguiente sería investigar el software, tanto en línea (¿tiene documentación?) como fuera de línea ( ss, strace, ipcs, ...) para determinar en detalle su diseño arquitectónico, a saber, entre otros:
archivos, que también deben dividirse en subgrupos (configuración, transacciones, registros, ...)
procesos, servicios (¿el software tiene un script systemd/upstart/init?)
Conectividad de red (tráfico entrante y saliente, puertos,...)
usuarios, grupos
Con toda esa información a mano, podrá comenzar a desarrollar una política para ese software.
Necesitaras:
crear un archivo filecontexts que defina el contexto de seguridad de todos los archivos involucrados
cree un archivo de interfaces que defina su dominio en términos de todas las interacciones entre archivos, procesos, puertos, usuarios, transiciones de dominio, ...
crear un archivo de aplicación de tipos que describa a qué usuarios se les concede acceso al dominio anterior y las reglas reales
Compílelo y cárguelo, verifique las denegaciones de AVC, depure y mejore su política. Enjuague y repita.
Del libro mencionado anteriormente, una última cita:
A algunos desarrolladores de políticas les gusta ejecutar el modo permisivo de la aplicación (ya sea ejecutando todo el sistema en modo permisivo o marcando este dominio en particular como un dominio permisivo), registrando todos los accesos realizados (a través de las denegaciones AVC) y mejorando la política en función de esa información. Aunque esto podría proporcionar una política de trabajo más rápida, estos desarrolladores también correrán el riesgo de agregar demasiados privilegios a una política, algo que es muy difícil de cuestionar y cambiar más adelante. En cambio, dejamos que SELinux impida los accesos y observemos cómo reacciona la aplicación. Según el registro de errores de la aplicación o el comportamiento de la aplicación y las denegaciones de AVC vistas a través de los registros, podemos tener una buena idea de qué privilegios son realmente necesarios.