¿Qué tan útil es el montaje / tmp noexec?

Muchas personas (incluido el Manual de seguridad de Debian ) recomiendan montar /tmpcon el noexec,nodev,nosuidconjunto de opciones. Esto generalmente se presenta como un elemento de una estrategia de 'defensa en profundidad', al evitar la escalada de un ataque que le permite a alguien escribir un archivo, o un ataque de un usuario con una cuenta legítima pero ningún otro espacio de escritura.

Sin embargo, con el tiempo, he encontrado argumentos (principalmente por el desarrollador de Debian / Ubuntu, Colin Watson) que noexeces una medida inútil, por un par de posibles razones:

1. El usuario puede ejecutar /lib/ld-linux.so <binary>en un intento de obtener el mismo efecto.
2. El usuario aún puede ejecutar intérpretes proporcionados por el sistema en scripts que no se pueden ejecutar directamente

Teniendo en cuenta estos argumentos, la posible necesidad de más configuración (p. Ej., debconfLe gusta un directorio temporal ejecutable) y la posible pérdida de comodidad, ¿es esta una medida de seguridad que vale la pena? ¿Qué otros agujeros conoces que permitan la elusión?

Aquí están los argumentos de utilidad que he encontrado hasta ahora:

Los núcleos modernos arreglan el /lib/ld-linux.soagujero, de modo que no podrá asignar páginas ejecutables desde un noexecsistema de archivos.

El punto de los intérpretes es ciertamente una preocupación, aunque creo que es 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 de sistema malformadas particulares. Sin un atacante que proporcione un binario, sería mucho más difícil hacer syscalls malvados. Además, los intérpretes de script no deben tener privilegios (sé que históricamente a veces no ha sido así, como con un 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 /tmp, y así noexecreducir la probabilidad de caer en un ataque programado (digamos en la ventana entre la divulgación de vulnerabilidad y la instalación del parche).

Por lo tanto, todavía hay una prestación de seguridad para el montaje /tmpcon noexec.

Como se describe en el rastreador de errores de Debian , la instalación APT::ExtractTemplates::TempDiren apt.confun directorio que no es noexecaccesible para el root evitaría la preocupación de debconf.

Muchos paquetes Debian requieren que / tmp sea ejecutable para que el paquete se instale. A menudo se marcan como errores (de gravedad 'normal' / 'lista de deseos'):

https://www.google.com/#q=site:bugs.debian.org+noexec+/tmp

Recibí solo este error al instalar un kernel actualizado en la rama estable hoy.

Entonces parece que Debian (¿y derivados?) No está listo para que / tmp se monte noexec ...

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";};

A pesar de que existen soluciones para la mayoría de las medidas de seguridad adicionales que puede optar por 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 automáticos o programados que se basan en los valores predeterminados en orden funcionar. No lo protegerá contra un atacante determinado y conocedor, pero más del 99% del tiempo, no se enfrentará a un atacante determinado o conocedor. En cambio, te defenderás de un script de ataque automatizado.

Primero: cubre muchos casos de ataque diferentes. Desactivarlo porque había algunas formas conocidas de evitarlo (algunas de las cuales incluso se solucionaron) es extraño. Los atacantes que descargan código a / dev / shm o / tmp es algo común que hacen.

La defensa en profundidad se trata de asegurar los puntos de referencia más comunes, cada uno que los detiene hace que su sistema sea más sobrevivible. No es seguro. Pero también tendrá una oportunidad . Si no pueden obtener su carga útil secundaria, es una muy buena oportunidad de que la obtengas.

• También podría ser detenido por las restricciones de usuario de iptables.
• También podría ser detenido por SELinux.
• También podría no detenerse debido a otro exploit de fácil acceso.

El punto es que sea lo más fuerte que fácilmente puede, y recortar el 99% de los ataques.

Segundo: detiene las malas prácticas (ejecuta cosas desde temp, realiza importantes instalaciones de aplicaciones a través de / tmp en lugar de un usuario tmpdir), dejando datos en / tmp. Los instaladores personalizados generalmente entienden TMPDIR. Además: incluso si no es así: el tiempo de instalación, como una acción de punto en el tiempo, no es una razón válida para desactivar un problema de seguridad de forma permanente .

Tercero: teniendo en cuenta los espacios de nombres anónimos en / tmp (una "característica"), realmente desea restringir lo que se pone allí y se ejecuta 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 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 gran razón? No lo creo.

Que tal este:

"Aprendimos que los enemigos pueden atacar sin previo aviso. También podrían usar cientos de espías para envenenar la comida. Así que dejamos de entregar armas a nuestros soldados".

¿Esperar lo?

Hay otras medidas que requieren mucho más esfuerzo, experiencia y suerte para asegurar un sistema, y ​​saber que las personas tienen dinero limitado, esperanza de vida y también les gustaría pasar tiempo con sus familias: no se salten las cosas fáciles.

Hay aplicaciones que requieren que / tmp sea ejecutable para la instalación. En un trabajo anterior, antes de llegar allí, los administradores habían configurado / tmp noexec, pero descubrí que el paquete db2 no se instalaría. Incluso si descomprime el paquete db2 en otro lugar, el procedimiento de instalación copia algunos archivos en / tmp y espera poder ejecutarlo, lo que, por supuesto, falló con el permiso denegado. Si no sabe que el sistema de archivos está montado noexec, puede ser un poco engañoso. Solo pude continuar la instalación después de volver a montar / tmp sin noexec.

De todos modos, el punto es que al menos un producto comercial requiere que / tmp no se monte noexec, y puede haber otros. No he encontrado una razón realmente convincente para ello. Si quieres una mayor seguridad, iría con selinux.