editar - linux easytag
¿Deshabilitas SELinux? (15)
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 herramientas y tutoriales que existen que lo ayudan a crear, corregir y definir políticas, no hay excusa para deshabilitarlo.
Quiero saber si las personas aquí normalmente desactivan SELinux en las instalaciones donde está activado por defecto. Si es así, ¿puedes explicar por qué, qué tipo de sistema era, etc.?
Me gustaría obtener tantas opiniones sobre esto como sea posible.
No tengo mucho para aportar aquí, pero como no recibió respuesta, pensé que invertiría mis dos centavos.
Personalmente, lo deshabilito en las cajas de desarrollo y cuando trato 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 usas realmente se reduce a tus necesidades, pero fue creado por una razón, así que considera utilizarlo 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 desactivarlo u ocultarlo para que solo los usuarios expertos sepan cómo hacerlo, y se supone que solo los usuarios son precisamente los que entienden el Consecuencias.
Con SELinux, hay un problema de huevo y 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 el tiempo suficiente como para informar al menos algunos problemas antes de que lo desactiven.
Al final, es su decisión: ¿busca una solución a corto plazo o una mejora a largo plazo del software, lo que eliminará la necesidad de hacer esa pregunta algún día?
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 configurar SELinux correctamente 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. Sin embargo, nunca se requiere SELinux por razones de seguridad, y esta 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 congele, y se encuentre una nueva vulnerabilidad, y las actualizaciones no estén a tiempo, y su sistema tenga la mala suerte de ser la zona cero ... SELinux podría salvar su culo.
Pero esa es una venta difícil.
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 solucionarlo con la herramienta de administración de configuración, Puppet .
Usamos la función de plantilla de Puppet para generar nuestras políticas. Vea Mejoras de SELinux para Puppet , encabezado "Future stuff", artículo "Policy Generation".
Aquí hay algunos pasos básicos de la forma en que implementamos esto. Nota aparte de audit2allow, esto fue todo automatizado.
Genere un archivo de plantilla SELinux para algún servicio llamado $ {nombre}.
sudo audit2allow -m "${name}" -i /var/log/audit/audit.log > ${name}.te
Cree 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, a la mayoría de la gente le conviene desconectar SELinux y fortalecer su sistema a través de otras mejores prácticas comúnmente aceptadas basadas en el consenso, como los puntos de referencia de The Center for Internet Security (tenga en cuenta que recomiendan SELinux :-)).
Tristemente, 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 propio producto Satellite 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 puede activarse y desactivarse 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.
Entonces, sea lo que sea que pensó que estaba haciendo para asegurar nuestros sistemas, rompiéndolos, ni siquiera lo hacía 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.
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 encendida 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.
Solía trabajar para un importante fabricante de computadoras en 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.
En Red-hat, puede editar /etc/sysconfig/selinux y establecer SELINIX=disabled .
Creo que en todas las versiones de Linux puedes agregar selinux=0 noselinux a la línea de arranque en lilo.conf o grub.conf.
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 correr 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.
No lo desactivo, pero hay algunos problemas.
Algunas aplicaciones no funcionan particularmente bien con él.
Por ejemplo, creo que habilité SmartD para tratar de hacer un seguimiento de mi estado inteligente de discos de banda, pero selinux se confundiría sobre los nuevos nodos /dev/sda* creados en el arranque (creo que ese era el problema)
Tienes que descargar la fuente a las reglas para entender las cosas.
Simplemente marque /var/log/messages para los /var/log/messages "avc denied" y puede decodificar lo que se está denegando.
google "selinux faq" y encontrarás una pregunta frecuente de fedora selinux que te dirá cómo solucionar estos problemas.