Gentoo Hardened vs otras distribuciones

¡Todo está en la fuente! Gentoo endurecido es una distribución impulsada por la seguridad, el perfil reforzado realmente incluye mucho para hacerlo realmente seguro.

¿Pero vale la pena la compilación? Una gran pregunta entre los foros de Linux.

Veamos el perfil reforzado de Gentoo en términos de seguridad:

mientras agrega algo de seguridad ridad es tan poco que no vale la pena en la mayoría de los casos. Proporciona más seguridad en una distribución binaria porque todos tienen los mismos binarios y un atacante no necesita adivinar dónde se puede cargar un fragmento de código específico, pero al ejecutar una distribución de origen, su espacio de direcciones ya es bastante único. El único caso en el que proporciona algo de seguridad cuando un atacante está tratando de adivinar una dirección para un exploit, hacer una suposición incorrecta probablemente bloqueará el proceso y se volverá a cargar en una nueva dirección. ¿Tiene datos lo suficientemente valiosos como para que un atacante pase por eso? ¿Problemas para conseguirlo? Si lo hace, entonces debería utilizar un perfil reforzado, pero la seguridad física y el cifrado del disco son más importantes porque si vale tanto, será más fácil simplemente robarle.

Tenga en cuenta que no hay un perfil de escritorio reforzado, por lo que por sí solo lo hará algo más difícil si planea usarlo en un escritorio.

Otra razón es si desea usar algo como SELinux (que no requiere un perfil reforzado) que le brinda un control muy fino sobre el control de acceso, pero también es muy restrictivo. Creo que solo vale la pena para redes grandes con muchos usuarios y diferentes niveles de acceso a datos confidenciales.

Necesitaba algunas de las características de SELinux pero me conformé con usar AppArmor de una manera inusual para lograrlas porque SELinux es demasiado problema. Todo lo que AppArmor realmente hace es proporcionar aislamiento de procesos o sandboxing. Si un atacante obtiene acceso a través de un exploint, solo podrá acceder a los archivos a los que tiene acceso el servicio explotado. Lo uso con un perfil de captura todo que evita la ejecución desde todos los directorios personales y de escritura del mundo, y el acceso a claves ssh / pgp, llaveros, etc. Esto funciona bien para servidores y escritorios y no es demasiado restrictivo. Y si necesito ejecutar código desde mi directorio personal para el desarrollo, puedo lanzar un shell sin restricciones a través de sudo. Puedo dejar mi computadora portátil desbloqueada con la billetera abierta (uso el módulo kwallet pam) y será muy difícil para usted obtener algo como claves ssh o contraseñas (también tengo parches para kwallet, por lo que requiere una contraseña ord para mostrar las contraseñas guardadas), pero los programas que las necesitan tienen acceso a ellas.

¿Pero qué lo endurece? veamos también algunos de esos elementos:

• PaX es un parche del kernel que nos protege de los desbordamientos de pila y montón. PaX hace esto mediante el uso de ASLR (distribución aleatoria del diseño del espacio de direcciones), que utiliza ubicaciones de memoria aleatorias en la memoria. Cada código de shell debe usar una dirección para saltar a incrustado en él con el fin de obtener la ejecución del código y, debido a que la dirección del búfer en la memoria es aleatoria, esto es mucho más difícil de lograr. PaX agrega una capa adicional de protección al mantener los datos utilizados por el programa en una región de memoria no ejecutable, lo que significa que un atacante no podrá ejecutar el código que logró escribir en la memoria. Para usar PaX, tenemos que usar un kernel habilitado para PaX, como fuentes reforzadas.
• PIE / PIC (código independiente de la posición): normalmente, un ejecutable tiene una dirección base fija donde están cargados. Esta es también la dirección que se agrega a los RVA para calcular la dirección de las funciones dentro del ejecutable. Si el ejecutable está compilado con soporte PIE, se puede cargar en cualquier lugar de la memoria, mientras que debe cargarse en una dirección fija si se compila sin soporte PIE. El PIE debe estar habilitado si queremos usar PaX para aprovechar ASLR.
• RELRO (reubicación de solo lectura): cuando ejecutamos el ejecutable, el programa cargado debe escribir en algunas secciones que no No es necesario marcarlo como grabable después de iniciar la aplicación. Estas secciones son .ctors, .dtors, .jcr, .dynamic y .got [4].Si marcamos esas secciones como de solo lectura, un atacante no podrá usar ciertos ataques que podrían usarse al intentar obtener la ejecución del código, como sobrescribir entradas en una tabla GOT.
• SSP ( protector de aplastamiento de pila) se usa en modo de usuario; protege contra desbordes de pila colocando un canario en la pila. Cuando un atacante quiere desbordar la dirección EIP de retorno en la pila, también debe desbordar el canario elegido al azar. Cuando eso sucede, el sistema puede detectar que el canary se ha sobrescrito, en cuyo caso la aplicación se termina, no permitiendo que un atacante salte a una ubicación arbitraria en la memoria y ejecute código desde allí.
• RBAC (control de acceso basado en roles): tenga en cuenta que RBAC no es lo mismo que RSBAC, que presentaremos más adelante. El RBAC es un control de acceso que puede ser utilizado por SELinux, Grsecurity, etc. Por defecto, el creador de un archivo tiene control total sobre el archivo, mientras que el RBAC obliga al usuario root a tener el control del archivo, independientemente de quién lo haya creado. eso. Por lo tanto, todos los usuarios del sistema deben seguir las reglas de RBAC establecidas por el administrador del sistema.

Además, también podemos utilizar los siguientes sistemas de control de acceso, que se utilizan para controlar el acceso entre procesos y objetos. Normalmente, tenemos que elegir uno de los sistemas que se describen a continuación, porque solo se puede usar uno de los sistemas de control de acceso a la vez. Los sistemas de control de acceso incluyen los siguientes:

• SELinux (Linux con seguridad mejorada)
• AppArmor (armadura de aplicaciones)
• Grsecurity, que contiene varios parches que se puede aplicar al kernel para aumentar la seguridad de todo el sistema. Si queremos habilitar Grsecurity en el kernel, debemos usar un kernel habilitado para Grsecurity, que es de fuentes reforzadas.
• RSBAC (control de acceso basado en conjuntos de reglas): Debemos usar el kernel rsbac-sources para construir un kernel con soporte rsbac.

¿Todo se reduce a la gran pregunta como se dijo anteriormente? ¿Vale la pena compilarlo? ¿Realmente se reduce a cómo o qué está obteniendo y vale la pena el esfuerzo? ¿O serás capaz de asegurar verdaderamente lo que no quieres que vean las miradas indiscretas?

Comentarios

• Bien, gracias por la aclaración de todos estas tecnologías de aplicación de la seguridad. Entonces, si entiendo su punto, estos elementos son muy útiles para mejorar la seguridad de un sistema; pero preguntas " ¿vale la pena la compilación? ". Entonces, ¿por qué no están habilitados de forma predeterminada en algunas distribuciones importantes? Leí que PaX en un escritorio puede romper algunos binarios (oído hablar de java o firefox); ¿Es la única razón?
• La razón por la que PaX y grsecurity no son los predeterminados en muchas distribuciones se debe a la política y el ego. Los desarrolladores de ambos tienen personalidades que chocan fuertemente con el equipo de desarrollo del kernel de Linux. Además de eso, no desean tomarse el tiempo para dividir su parche en partes que serían aceptadas en el flujo ascendente y, en su lugar, usar su tiempo para desarrollar más funciones de seguridad.
• También tenga en cuenta que grsecurity es no es un sistema de control de acceso. Spender (creador de grsecurity) se irrita mucho cuando la gente lo llama sistema de control de acceso y luego lo compara con SELinux. : P Grsecurity es una combinación de parches del kernel que aumenta la seguridad del kernel al eliminar las clases de errores. El sistema de control de acceso RBAC que tiene es intrascendente en comparación con el resto. Las características de seguridad de Grsecurity ' son tan amplias que ocuparían mucho más espacio del que se podría poner en una sola publicación. Visite grsecurity.net para ver una lista bastante completa.
• si bien agrega algo de seguridad, ' es tan pequeño que ' no vale la pena en la mayoría de los casos – Uh, esto es totalmente incorrecto. Y la seguridad realmente no tiene nada que ver con ocultar direcciones. Estoy ' m sorprendido de que esta respuesta sea votada a favor.