Estoy intentando aislar algunos procesos que no son de confianza utilizando los marcos MAC de Linux, ya sea SELinux o AppArmor.
Veo que tanto SELinux como AppArmor permiten el otorgamiento seleccionado de acceso a nivel de socket para el programa que se está en un espacio aislado. Sin embargo, ¿es posible realizar un control más preciso, como restringir la actividad de la red a solo un conjunto de direcciones IP y / o tipos específicos de tráfico (por ejemplo, solo TCP / UDP)?
Descargo de responsabilidad: estoy lejos de ser un experto en SELinux o AppArmor, por lo que deberá comprobar todo lo que digo por usted mismo.
Creo que hay una manera de hacer que SELinux e IPTables trabajen juntos. SELinux puede etiquetar paquetes con una etiqueta que indica el contexto / origen / procedencia de SELinux que se aplica al paquete. Luego, puede escribir reglas de IPTables que inspeccionen esta etiqueta para aplicar una política de firewall diferente dependiendo del valor de esta etiqueta. Esto parece ser una forma potencial de realizar un control más preciso, por ejemplo, para exigir que una aplicación en particular solo pueda comunicarse con un determinado número de puerto o protocolo. Referencias: haciendo que SELinux e IPTables se hablen entre sí , un artículo sobre este y la discusión correspondiente sobre LWN , y antecedentes de Secmark, el subsistema de marcado de paquetes .
Para AppArmor, que yo sepa, esto no está soportado actualmente. Hay una entrada del rastreador de errores que solicita esta función.
Creo que Systrace ya tiene soporte para este tipo de control integrado, integrado.
Para agregar una nota de experiencia personal a lo anterior, el uso de selinux junto con iptables hace que tanto la política como sus iptables se vean extremadamente complicadas y complicadas. Es uno de esos casos en los que la compensación de la complejidad realmente debe valer la pena, a menos que esté asegurando una instalación militar donde el etiquetado correcto de paquetes signifique la vida o la muerte, no lo recomendaría.
SELinux proporciona algunas etiquetas básicas de puerto / protocolo que no se relacionan con iptables. P.ej. si ejecuta semanage port -l le dará una lista de todos los puertos definidos en la política de destino. Puede usar esto para restringir en qué puertos se puede comunicar un dominio SELinux. Por ejemplo, puede escribir una política que indique que myapp_t solo puede vincularse a myapp_port_t y conectarse a http_port_t . Esto ya es bastante bueno: si un atacante logra explotar la aplicación, no podría vincularse a ningún otro puerto o conectarse a otra cosa que no sea 80 / tcp (por ejemplo, esto frustraría un intento de conexión a IRC). / p>
Si realmente estuviera interesado en eso, podría ir más allá y decir: etiquetar todos los paquetes creados por myapp_port_t como myapp_packet_t y configurar el firewall para que solo pase de myapp_packet_t a -d 10.10.10.1 --dport 443 . Luego, si un atacante lograba explotar esa aplicación, solo podría comunicarse con 10.10.10.1 en el puerto 443, mientras que otras aplicaciones, como un navegador, no estarían restringidas de otra manera.
Dicho esto, aunque en teoría es asombroso, en la práctica las aplicaciones producen mucho más paquetes de tráfico que solo un tcp saliente en el puerto 443. Una aplicación tendría que hacer nslookups (por lo tanto, debe permitir que myapp_packet_t udp al puerto 53 ), y si su información de usuario proviene de ldap, probablemente generará tráfico de ldap. Como resultado, sus políticas y sus iptables rápidamente se convierten en monstruosidades inmanejables. Recomiendo apegarse al etiquetado básico de puertos. :)
Lea otras preguntas en las etiquetas network linux access-control selinux apparmor