Solución 1:
Estos son los argumentos a favor de la utilidad que se me han ocurrido hasta ahora:
Los núcleos modernos corrigen el /lib/ld-linux.so agujero, por lo que no podrá asignar páginas ejecutables desde un noexec sistema de archivos.
El punto de los intérpretes ciertamente sigue siendo una preocupación, aunque creo que menos de lo que la gente podría afirmar. El razonamiento que se me ocurre es que ha habido numerosas vulnerabilidades de escalada de privilegios que dependían de hacer llamadas al sistema mal formadas. Sin un atacante que proporcione un binario, sería mucho más difícil realizar llamadas al sistema malvadas. Además, los intérpretes de secuencias de comandos no deben tener privilegios (sé que históricamente a veces no ha sido así, como con suid perl), por lo que necesitarían su propia vulnerabilidad para ser útiles en un ataque. Aparentemente, es posible usar Python, al menos, para ejecutar algunos exploits.
Muchos exploits 'enlatados' pueden intentar escribir y ejecutar ejecutables en /tmp , y así noexec reduce la probabilidad de caer en un ataque programado (por ejemplo, en la ventana entre la divulgación de la vulnerabilidad y la instalación del parche).
Por lo tanto, todavía hay un beneficio de seguridad para montar /tmp con noexec .
Como se describe en el rastreador de errores de Debian, configurando APT::ExtractTemplates::TempDir en apt.conf a un directorio que no es noexec y accesible para root evitaría la preocupación de debconf.
Solución 2:
Muchos paquetes de Debian requieren que /tmp sea ejecutable para que el paquete se instale. Estos a menudo se marcan como errores (de gravedad 'normal'/'lista de deseos'):
https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp
Recibí este error justo hoy mientras instalaba un kernel actualizado en la rama estable.
Así que parece que Debian (¿y derivados?) no está listo para montar /tmp noexec...
Solución 3:
agregue lo siguiente a /etc/apt.conf, o /etc/apt/apt.conf.d/50remount
DPkg::Pre-Install-Pkgs {"mount -o remount,exec /tmp";};
DPkg::Post-Invoke {"mount -o remount /tmp";};
Solución 4:
Aunque existen soluciones alternativas para la mayoría de las medidas de seguridad complementarias que podría elegir implementar, incluso las medidas de seguridad más fáciles de eludir (como montar /tmp noexec o ejecutar SSH en un puerto alternativo) frustrarán los ataques automatizados o con secuencias de comandos que se basan en los valores predeterminados en orden. funcionar. No lo protegerá contra un atacante determinado y experto, pero más del 99 % de las veces, no se enfrentará a un atacante determinado o informado. En su lugar, se estará defendiendo de un script de ataque automatizado.
Solución 5:
Primero: Cubre muchos casos de ataque diferentes. Apagarlo porque había algunas formas conocidas de evitarlo (algunos de los cuales incluso se arreglaron) es extraño. Atacantes descargando código a /dev/shm o /tmp es algo común que hacen.
La defensa en profundidad se trata de asegurar los waypoints más comunes, cada uno de los cuales los detiene hace que su sistema tenga más capacidad de supervivencia. No es seguro. Pero también tendrá una oportunidad . Si no pueden obtener su carga útil secundaria, es muy probable que lo estés obteniendo.
- También puede ser detenido por restricciones de usuario de iptables.
- También puede ser detenido por SELinux.
- También podría no detenerse debido a otro exploit de fácil acceso.
El punto es hacerlo tan difícil como tú fácilmente puede, y eliminó el 99% de los ataques.
Segundo: Detiene las malas prácticas (ejecutar cosas de manera temporal, realizar instalaciones de aplicaciones importantes a través de /tmp en lugar de un usuario tmpdir), dejando los datos en /tmp .Los instaladores personalizados generalmente sí entienden TMPDIR Además:incluso si no:el tiempo de instalación, como una acción puntual, no es una razón válida para desactivar un problema de seguridad permanentemente .
Tercero: Considerando espacios de nombres anónimos en /tmp (una "característica"), realmente desea restringir lo que se coloca allí y ejecutar desde allí.
Cuarto: La conveniencia no es un factor relevante en esto. Suponiendo que ejecutamos servidores por dinero y con un propósito:somos responsables de estas cosas. "Oh, no bloqueé /tmp porque luego necesito unos minutos más cuando actualice mi software el próximo año". Seguramente no será solo esto lo que se interpone entre ser chantajeado y estar bien. ¿Una buena razón? No lo creo.
Que tal este:
"Aprendimos que los enemigos pueden atacar sin previo aviso. También pueden usar cientos de espías para envenenar la comida. Así que dejamos de darles armas a nuestros soldados".
Espera, ¿QUÉ?
Hay otras medidas que requieren mucho más esfuerzo, experiencia y suerte para asegurar un sistema, y sabiendo que las personas tienen dinero limitado, esperanza de vida y también les gustaría pasar tiempo con sus familias:No se salte las cosas fáciles.