¿Cómo ayuda la seguridad a la separación de las preocupaciones en procesos separados (sin cumplimiento)?

Question

¿Cómo ayuda la seguridad a la separación de las preocupaciones en procesos separados (sin cumplimiento)?

#1 de Gilles (2 votos)

1

En esta charla sobre la separación de privilegios, Theo de Raadt explica que el ntpd de OpenBSD tiene un proceso maestro que llama a settimeofday() , un proceso de DNS responsable de consultar los servidores de DNS y un proceso de protocolo NTP que es responsable de hablar de UDP a los servidores de NTP. Tiene esto que decir sobre el proceso de DNS:

La otra cosa que tenemos es un proceso de servicio DNS independiente, porque queríamos poder hacer DNS, pero no queríamos que el proceso maestro lo hiciera porque las bibliotecas DNS a veces tienen errores, y no lo hicimos No quiero que el altavoz de Internet lo haga porque ... es ... simplemente no tiene sentido.

Supongamos que el compromiso no existe (este diseño es anterior, como yo lo entiendo). Obviamente, este diseño es bastante inútil por sí solo, ya que si el servicio orientado a la red está comprometido, el atacante tiene una raíz en el sistema. Por lo tanto, el proceso maestro bifurcará ambos subprocesos, lo que inmediatamente quitará los privilegios a nobody o algo así. De esa manera, si hay un error de seguridad en la biblioteca DNS o en el código NTP, el atacante no tiene acceso de escritura al archivo del sistema, a los directorios principales, etc.

Todo eso tiene sentido para mí. Sin embargo, lo que no entiendo es por qué es útil la separación entre los procesos de DNS y UDP. No importa cuál está comprometido; el atacante se ejecuta como el mismo usuario de cualquier manera. Podría poner el proceso de DNS en, por ejemplo. un usuario nobody2 , pero incluso entonces, nobody2 será tan poco privilegiado como nobody .

Con el compromiso, el beneficio es obvio ya que, por ejemplo, el proceso de DNS puede prometer que solo realizará consultas de DNS, lo que será bastante inútil para un atacante. Sin embargo, estamos asumiendo que el compromiso no es un factor importante ya que este diseño se introdujo antes del compromiso.

¿Hay algún beneficio de seguridad para el diseño de tres procesos ntpd que me estoy perdiendo? ¿O fue solo una decisión de diseño no relacionada con la seguridad (tal vez considerando la posibilidad de un futuro sistema de compromiso)?

openbsd privilege-separation principle-of-least-privilege

pregunta strugee 04.01.2017 - 23:39

fuente

1 respuesta

Lea otras preguntas en las etiquetas openbsd privilege-separation principle-of-least-privilege

¿Un demonio para saber cuándo acceden las aplicaciones a la cámara del teléfono celular? Seguridad del enrutador de borde de reenvío de puerto

score 2 · Accepted Answer

(Tenga en cuenta que no sé nada sobre el diseño de OpenBSD ntpd, solo estoy respondiendo la pregunta genérica sobre procesos de separación).

De su cita, deduzco que la separación del proceso UDP del proceso DNS no fue motivada por preocupaciones de seguridad, sino por preocupaciones arquitectónicas: "porque ... es ... simplemente no tiene sentido". El proceso UDP y el proceso DNS reaccionan ante eventos completamente diferentes. Si estuvieran en el mismo proceso, usarían hilos separados (ya sea explícita o implícitamente con un bucle de eventos alrededor de una llamada select ). Dado que el proceso UDP y el proceso DNS funcionan de forma independiente, colocarlos en el mismo proceso complicaría el diseño, por lo que, de forma predeterminada, están en procesos distintos.

Si el servidor NTP se hubiera diseñado como un proceso único, el diseño habría tenido que adaptarse a los diferentes patrones de interacción de los subsistemas. Entonces los hilos habrían tenido sentido. Pero si de todos modos, si hay separación de procesos, agrupar subsistemas no relacionados en el mismo proceso complica el diseño.

No obstante, puede haber beneficios de seguridad al tener procesos separados. Un beneficio es que no todas las vulnerabilidades permiten al atacante ejecutar código arbitrario. Algunas vulnerabilidades solo permiten la corrupción localizada de los datos, o la exposición de algunos datos secretos, o pueden causar un bloqueo, pero siempre de forma controlada (por ejemplo, solo una diferencia de puntero nulo y no una diferencia de puntero arbitrario). Incluso si una vulnerabilidad permite la ejecución de código arbitrario, a veces escribir un exploit es complicado, y hacer los exploits más complicados le da tiempo al defensor para corregir el error e implementar las actualizaciones.

Incluso si una vulnerabilidad permite la ejecución de código arbitrario en un proceso, los mecanismos a nivel del sistema operativo podrían limitar el proceso. Incluso antes de pledge , OpenBSD permitía una restricción de todo el sistema operativo en ptrace , que debería estar habilitada en un servidor de producción. Un proceso que se ejecuta como nobody no puede dañar directamente otros procesos si no puede seguirlos. El atacante tendría que encontrar algunos medios indirectos, y mientras abundan las oportunidades para DoS, una violación del DNS no permitiría que el atacante genere tráfico NTP falso, por ejemplo (no podría enlazar el puerto). p>