Quiero saber si las personas aquí normalmente deshabilitan SELinux en las instalaciones donde está activado por defecto? Si es así, ¿puedes explicar por qué, qué tipo de sistema era, etc.?¿Deshabilita SELinux?
Me gustaría obtener la mayor cantidad de opiniones al respecto.
no tengo mucho que aportar aquí, pero desde su quedado sin respuesta, pensé que podría tirar mis dos centavos en.
Personalmente, desactivarlo en cajas dev y cuando estoy tratando con cosas sin importancia. Cuando estoy lidiando con algo de producción, o que requiere una mayor seguridad, lo dejo y/o paso el tiempo retocándolo para manejar las cosas como lo necesito.
El tiempo o no lo usa realmente se reduce a sus necesidades, pero fue creado por una razón, así que considere usarlo en lugar de apagarlo siempre.
SELinux requiere la atención del usuario y la concesión de permisos manuales cada vez que (oh, bueno) no tiene permiso para algo. Mucha gente encuentra que se interpone en el camino y lo apaga.
En la versión más reciente, SELinux es más fácil de usar, e incluso se habla de eliminar la posibilidad de apagarlo u ocultarlo para que solo los usuarios expertos sepan cómo hacerlo, y se supone que los usuarios son precisamente aquellos que entienden las consecuencias.
Con SELinux, hay un problema con el huevo y la gallina: para tenerlo todo el tiempo, usted como usuario debe informar los problemas a los desarrolladores, para que puedan mejorarlo. Pero a los usuarios no les gusta usarlo hasta que se mejore, y no se mejorará si no muchos usuarios lo están usando.
Por lo tanto, se deja activado por defecto con la esperanza de que la mayoría de la gente lo use durante el tiempo suficiente como para informar al menos algunos problemas antes de que se apaguen.
Al final, es su llamada: ¿busca una solución a corto plazo, o una mejora a largo plazo del software, lo que llevará a eliminar la necesidad de hacer esa pregunta algún día.
Lo hice, hace tres o cuatro años cuando las políticas definidas tenían muchas dificultades y la creación de políticas era demasiado difícil y no tenía 'tiempo' para aprender. Esto fue en máquinas no críticas, por supuesto.
Hoy en día, con todo el trabajo realizado para enviar distribuciones con políticas sensatas, y las tools y tutorials que existen que ayudan a crear, corregir y definir políticas, no hay excusa para deshabilitarlas.
¡¡¡uf !! ¡No estoy solo! –
¡Estoy contigo, amigo! – Gabe
Escuché que está mejorando, pero todavía lo deshabilito. Para los servidores, realmente no tiene sentido a menos que sea un ISP o una gran corporación que desee implementar controles de nivel de acceso de grano fino en múltiples usuarios locales.
Al usarlo en un servidor web, tuve muchos problemas con los permisos de apache. Tendría que ejecutar constantemente,
chcon -R -h -t httpd_sys_content_t /var/www/html
para actualizar las ACL cuando se agregaron nuevos archivos. Estoy seguro de que esto ya se ha resuelto, pero aun así, SELinux siente mucho dolor por la recompensa limitada que se obtiene al habilitarlo en una implementación estándar del sitio web.
recompensa limitada? en un sitio web frente a Internet? ¿En qué mundo estás viviendo? –
Estoy de acuerdo con la "recompensa limitada?" pregunta. Selinux ha salvado mi servidor web de ser pirateado debido a un error de seguridad en un paquete utilizado por httpd donde selinux impidió que el exploit funcione. – Eddie
No lo desactivo, pero hay algunos problemas.
Algunas aplicaciones no funcionan especialmente bien con ella.
Por ejemplo, creo que habilité smartd para tratar de realizar un seguimiento de mis discos de incursión s.m.a.r.t. estado, pero selinux se confundiría con los nuevos nodos /dev/sda* creados en el arranque (creo que ese es el problema)
Tienes que descargar el código fuente para entender las cosas.
Simplemente marque /var/log/messages para los mensajes "avc denied" y puede decodificar lo que se está denegando.
google "selinux faq" y encontrará una pregunta frecuente de fedora selinux que le indicará cómo solucionar estos problemas.
Trabajé para una empresa el año pasado donde lo estábamos aplicando con la política 'dirigida' habilitada en los sistemas CentOS 5.x. No interfirió con ninguno de los códigos de aplicaciones web en los que trabajaron nuestros desarrolladores porque Apache estaba en la política predeterminada. Causó algunos desafíos para el software instalado de paquetes que no son de Red Hat (o CentOS), pero logramos solventarlo con la herramienta de administración de configuración, Puppet.
Utilizamos la función de plantilla de Puppet para generar nuestras políticas. Consulte SELinux Enhancements for Puppet, título "Cosas futuras", elemento "Generación de directivas".
Aquí hay algunos pasos básicos de la forma en que implementamos esto. Nota aparte de audit2allow, esto fue todo automatizado.
Genera un archivo de plantilla SELinux para algún servicio llamado $ {nombre}.
sudo audit2allow -m "${name}" -i /var/log/audit/audit.log > ${name}.te
Crear una secuencia de comandos, /etc/selinux/local/${name}-setup.sh
SOURCE=/etc/selinux/local
BUILD=/etc/selinux/local
/usr/bin/checkmodule -M -m -o ${BUILD}/${name}.mod ${SOURCE}/${name}.te
/usr/bin/semodule_package -o ${BUILD}/${name}.pp -m ${BUILD}/${name}.mod
/usr/sbin/semodule -i ${BUILD}/${name}.pp
/bin/rm ${BUILD}/${name}.mod ${BUILD}/${name}.pp
Dicho esto, la mayoría de la gente es mejor simplemente deshabilitar SELinux y endurecer su sistema a través de otras mejores prácticas basadas en el consenso comúnmente aceptada como The Center for Internet Security's Benchmarks (tenga en cuenta que recomiendan SELinux :-)).
En Red-hat, puede editar /etc/sysconfig/selinux y establecer SELINIX=disabled.
Creo que en todas las versiones de Linux puede agregar selinux=0 noselinux a la línea de arranque en lilo.conf o grub.conf.
Realmente no está respondiendo la pregunta. – Saustrup
Mi empresa crea un producto de plataforma de integración/CMS. Muchos de nuestros clientes tienen sistemas heredados de terceros que aún tienen importantes datos operativos en ellos, y la mayoría quiere seguir utilizando estos sistemas porque simplemente funcionan. Así que enganchamos nuestro sistema para extraer datos para publicar o informar, etc. a través de diversos medios. Tener toneladas de material específico para el cliente ejecutándose en cada servidor hace que la configuración de SELinux sea una tarea difícil y, por consiguiente, costosa.
Muchos clientes inicialmente quieren lo mejor en seguridad, pero cuando escuchan el costo estimado de nuestra solución de integración, las palabras 'SELinux desactivado' tienden a aparecer en el plan del proyecto bastante rápido.
Es una pena, ya que la defensa en profundidad es una buena idea. SELinux nunca es requiere para la seguridad, sin embargo, y esto parece ser su caída. Cuando el cliente pregunta '¿Puedes asegurarlo sin SELinux?', ¿Qué se supone que debemos responder? 'Umm ... no estamos seguros'?
Podemos y lo haremos, pero cuando el infierno se congela, y se encuentra una nueva vulnerabilidad, y las actualizaciones simplemente no están a tiempo, y su sistema tiene la mala suerte de ser la zona cero ... SELinux solo podría salvarte el culo.
Pero esa es una venta difícil.
¿Quieres decir que resulta que emacs C-m M-c M-butterfly se dirige tanto a los discos duros de las máquinas remotas como a los locales? – Joshua
Lamentablemente, apago SELinux la mayor parte del tiempo también, porque una buena cantidad de aplicaciones de terceros, como Oracle, no funcionan muy bien con SELinux activado y/o no son compatibles con plataformas que ejecutan SELinux.
Tenga en cuenta que el producto Satellite propio de Red Hat requiere que también desactive SELinux, lo que, una vez más, lamentablemente, dice mucho sobre las dificultades que tienen las personas para ejecutar aplicaciones complejas en plataformas habilitadas para SELinux.
Consejos de uso que pueden o no serle útiles: SELinux se puede activar y desactivar en tiempo de ejecución utilizando setenforce (use getenforce para verificar el estado actual). restorecon puede ser útil en situaciones donde chcon es engorroso, pero ymmv.
Nunca deshabilité selinux, mi contratista TIENE que usarlo. Y, si/cuando, algún daemon (con licencia OSS por cierto) no tiene una política de seguridad, es obligatorio escribir uno (bueno). Esto no se debe a que creo que selinux es un MAC invulnerable en Linux, inútil para poner el ejemplo, sino porque de todos modos aumenta mucho la seguridad del sistema operativo. Para la aplicación web, la mejor solución de seguridad de OSS es mod_security: así que uso ambos. La mayoría del problema con Selinux está en el docu pequeño o comprensible, aunque la situación ha mejorado mucho en los últimos años.
Sí. Está muerto cerebralmente. Puede presentar una rotura a daemons estándar que es casi imposible de diagnosticar. También puede cerrar una puerta, pero dejar una ventana abierta. Es decir, por alguna razón en instalaciones nuevas de CentOS estaba bloqueando que smbd partiera de "/etc/init.d/smb". Pero no lo bloqueó para que no se inicie cuando se invoca como "sh /etc/init.d/smb" o "smbd -D" o para mover el archivo init.d/smb a otro directorio, desde el cual comenzaría smbd solo multa.
Así que lo que sea que pensó que estaba haciendo para asegurar nuestros sistemas - al romperlos - ni siquiera estaba haciendo de manera consistente. Consultando a algunos gurús de CentOS serios, tampoco entienden las inconsistencias de su comportamiento. Está diseñado para hacerte sentir seguro. Pero es una fachada de seguridad. Es un sustituto para hacer el verdadero trabajo de bloquear la seguridad de su sistema.
Lo estás haciendo mal. La forma correcta es 'run_init service
Si está activado de manera predeterminada, lo dejaré encendido hasta que se rompa algo y luego se apagará.
Personalmente, veo que no proporciona ninguna seguridad y no voy a molestarme con eso.
Una caja de CENTOS que tenía como máquina de desarrollo tenía en y la apagué. Estaba deteniendo algunas cosas que intentaba hacer al probar la aplicación web que estaba desarrollando. El sistema estaba (por supuesto) detrás de un cortafuegos que bloqueaba por completo el acceso desde el exterior de nuestra LAN y tenía muchas otras medidas de seguridad, por lo que me sentí razonablemente seguro incluso con SELinux desactivado.
Trabajé para un importante fabricante de computadoras en el soporte de 3er nivel para RedHat Linux (así como otros dos sabores) que se ejecutan en los servidores de esa compañía. En la gran mayoría de los casos, hemos desactivado SELinux. Mi sensación es que si REALMENTE NECESITA SeLinux, SABE que lo necesita y puede indicar específicamente por qué lo necesita. Cuando no lo necesita, o no puede expresar claramente por qué, y está habilitado por defecto, se da cuenta rápidamente de que es un dolor en la parte trasera. Ve con tu intuición.
Lo apago en todos mis cuadros de cPanel, ya que cPanel no se ejecutará con él.
Si usa cPanel, probablemente no sea el público objetivo de SELinux. – Saustrup
Esto se debe migrar a unix.stackoverflow.com o al menos SuperUser donde tenga sentido. Y luego se abrió para la discusión. –