TL; DR

Establezca niveles de acceso para aplicaciones web individuales.

Leyó

Después de leer esta página , creo que tengo una buena idea del fundamento. En SELinux, cada archivo tiene un contexto de seguridad. Puede ver el contexto de seguridad actual con ls -Z <path> y configurar un nuevo contexto de seguridad con chcon .

Todas las aplicaciones web se ejecutarán como usuario apache , por lo que en circunstancias normales, cada aplicación web tendrá los mismos permisos. Con contextos de seguridad, puede limitar el acceso de aplicaciones / scripts individuales. De forma predeterminada, los scripts tienen acceso de solo lectura.

Esto es realmente muy útil para la seguridad. Digamos que tiene una aplicación en la que confía, que requiere acceso de escritura. Le darías explícitamente a ese script el contexto httpd_unconfined_script_exec_t . Ahora digamos que usted tiene una aplicación insegura que es propensa a explotar. Debería dejar el contexto de seguridad de los scripts que pertenecen a esa aplicación en el valor predeterminado, lo que impide la escritura de archivos.

La prevención de escrituras de archivos evitaría una amplia gama de ataques que aprovechan alguna vulnerabilidad para escribir un script en el disco, que puede posteriormente será ejecutado sobre http por el atacante.

Creo que parte de la respuesta se relaciona con algo que mencionas:

  

Estoy acostumbrado a configurar correctamente los permisos de los archivos Posix, por lo que uno de los primeros pasos que siempre realizo es chown apache: apache -R / var / www /. Posteriormente, solo uso el usuario de apache para interactuar con webroot o las aplicaciones web.

¿Por qué haces esto?

Es muy probable que ayude a proteger su sistema de un proceso fraudulento o compromiso.

seLinux es otra capa / mecanismo para ayudar a lograr lo mismo.

Un enfoque sensato (y de mejores prácticas) para la seguridad es estrechar sus defensas y, más en general, intentar y utilizar varios medios para proteger su sistema. Si se superponen, excelente: mientras más diferentes sean las formas de proteger la misma cosa, más necesitará un atacante para lograr sus objetivos.

La idea básica con seLinux para evitar escrituras (o lecturas) es que, al igual que con POSIX, debe otorgar explícitamente el acceso a un programa que requerirá.

/var/www en un gran número de casos será legítimamente de solo lectura: los sitios estáticos serían un caso obvio. En su caso, no menciona nunca chmod 'ing / var / www, por lo que es muy probable que sea 750 (o 700) y que sea propiedad de apache.

En ese caso, seLinux es, al menos, lo que le hace pensar si ese chmod y su nivel de acceso son realmente necesarios: a menos que en realidad necesite escribir archivos, probablemente no lo sea, y Parece razonable decir que seLinux de hecho está ayudando a evitar que la funcionalidad / acceso esté disponible y no sea necesario.

Se está enfocando en las cualidades similares a POSIX, pero seLinux también le permite evitar que Apache inicie conexiones salientes, por ejemplo, y puede restringir las conexiones salientes que se permiten a una pequeña cantidad de puertos. Personalmente, a veces me parece útil ver las capacidades de seLinux como algo similar a un daemon auditd exigente: usted está observando el comportamiento y puede ser mucho más específico sobre el comportamiento aceptable, de lo que POSIX hace posible (en parte porque POSIX no se trata tanto de protección, y más sobre compatibilidad y proporcionar un conjunto de características básicas y estables).

Podría pagar para leer lo que Wikipedia tiene que decir sobre POSIX y SELinux - y también para considerar el hecho de que POSIX proporciona Control de acceso discrecional , donde seLinux proporciona Control de acceso obligatorio .

Las diferencias DAC / MAC son una clave de punto para responder a su pregunta: MAC es generalmente una política de todo el sistema que se controla de forma centralizada (por lo general, con el objetivo de garantizar que el sistema funcione correctamente), donde DAC permite decisiones locales Por hacer: existe una tensión obvia entre estos enfoques, y el seLinux está ahí para garantizar que la política global se aplique incluso frente a las decisiones locales que podrían socavarla.

  

No puedo entender esta restricción de acceso a archivos, conociendo un administrador de sistemas   podría simplemente hacer chmod -R -w /var/www/html/

Creo que la amenaza aquí no es el usuario que intenta acceder a sus propios archivos, sino el programa que está siendo explotado.

Imagine que Firefox es víctima de un ataque de corrupción de memoria que le permite al atacante ejecutar código arbitrario: si SELinux restringe el acceso de Firefox a los únicos archivos que necesita para funcionar, no puede hacer daño en ningún otro lugar, como sus archivos personales y el resto. del sistema.

Además, habla de un sysadmin , lo que me hace pensar que debería definir con mayor precisión contra qué cree que SELinux defiende el sistema. El administrador del sistema tiene acceso a la raíz por definición y, por lo tanto, nada puede impedirle hacer nada. SELinux mitiga las vulnerabilidades de usuarios y programas, pero no puede hacer milagros.