SELinux lo protegerá contra los errores creados por la comunidad de Chromium y sus "oopses" o "características ocultas" de ese navegador. No puede poner todos los huevos en una canasta cuando se trata de seguridad. Aquí, algunos ejemplos donde deshabilitar selinux no puede ser una buena idea:
-
SELinux impide que Chrome-Sandbox tenga acceso de escritura en el archivo oom_score_adj : regresión que Chromium Los desarrolladores intentan culpar a Selinux cuando es su culpa. Se introdujo en una actualización y Chromium estaba tratando de manipular la memoria insuficiente. Claramente, cualquier sistema MAC lo negará, ya que es bastante obvio que no es "genial" listarse a sí mismo como un proceso para no ser asesino en un escenario OOM.
-
SELinux está impidiendo / opt / google / chrome / chrome-sandbox "write" access en oom_adj - En este caso, un descriptor de archivo filtrado evitaría la muerte de Chromium en casos de OOM. Claramente, un error que afectaría a cualquier sistema sin SELinux. Una regresión / "característica oculta" que fue bloqueada por SELinux.
-
"Aw, Snap!" en la base de datos abierta (por ejemplo, mientras se carga Twitter) en Fedora 15 con el cumplimiento de SELinux habilitado : algunos sitios se bloqueaban cuando un renderizado de Chromium pasa los descriptores de archivo a Chrome-Sandbox. Un error en las etiquetas de los archivos que podrían solucionarse con
restorecon -R ~/.config
cromo para bloquearse al renderizar algunos sitios. Claramente, un error en el cromo que SELinux previno posibles daños. Si se toma un tiempo para leer los comentarios, notará que algunos desarrolladores ni siquiera saben por qué se está estrellando, y otros se apresuran a decir "deshabilitar SELinux". No está bien ...
-
Problemas de Fedora SELinux con el lanzamiento de Chrome : el lanzamiento de cromo sin caja de arena (
google-chrome --no-sandbox
) funciona, mientras que con sandbox después de actualizar a la versión "14.0.803.0 dev" no. Chromium agregó ASLR en el momento de la compilación, pero SELinux estaba bloqueando relocalizaciones de texto . SELinux no tiene una bola de cristal para adivinar que los comandos binarios de Chromium están siendo probados como bibliotecas mediante el comando file
después de que el navegador agregó esta función de seguridad, y era su deber bloquear este tipo de comportamiento. Chromium estaba tratando de mejorar la seguridad, pero olvidó que esas reubicaciones de texto son, de hecho, vectores de ataques por bibliotecas que están mal codificadas .
-
Lo mejor : SELinux evita que google-chrome lea el archivo / etc / passwd : No es necesario explicar aquí. ¿Por qué el maldito navegador querría leer tu archivo de contraseña? Los desarrolladores de cromo no dieron una explicación consistente sobre el problema. Prueba aquí .
SELinux lo hace, de hecho, mejora la seguridad y crea otra capa para protegerlo de las funciones dañadas introducidas en las actualizaciones de Chromium.
¿Qué debe bloquear la política predeterminada?
Citaré a Dan Walsh en su livejournal , donde explica los conceptos básicos de la Política de Chrome. Esta es una explicación que se dio en la fecha en que se concibió esta política, y básicamente:
SELinux impide que Chrome-Sandbox:
Hacer cumplir el privilegio mínimo y todo lo que no esté permitido se bloqueará. Por lo tanto, en cualquier momento, chromium implementa algo nuevo que colide con las políticas predeterminadas (y recuerde que las políticas de SELinux son MÁS ANTIGUAS que su navegador), obtendrá un AVC.
Y esto no está siendo malo con el cromo. Este es el comportamiento predeterminado entre cualquier software que esté limitado por las políticas de SELinux.
Enlaces relacionados (documentos adicionales):