El investigador de seguridad e ingeniero de Microsoft Mickaël Salaün propone un soporte chroot sin privilegios para el kernel de Linux.
Con un parche enviado hoy, señaló:
“La llamada al sistema chroot está actualmente limitada para ser utilizada por procesos con la capacidad CAP_SYS_CHROOT. Esto protege contra procesos maliciosos dispuestos a engañar a los binarios tipo SUID.
El siguiente parche permite a los usuarios sin privilegios usar chroot de forma segura. (2) … Ser capaz de cambiar fácilmente los directorios raíz permite facilitar el flujo de trabajo de desarrollo y puede usarse como una herramienta para fortalecer las cajas de arena de seguridad sin privilegios.
Chroot (2) no es un mecanismo de control de acceso per se, pero puede ser se utiliza para limitar la vista absoluta del sistema de archivos y luego limitar las formas de acceder a los datos y las interfaces del kernel “.
El parche propuesto permite que las tareas no_new_privs llamen a chroot. Salaün continuó argumentando su caso en el mensaje del parche:
Es posible que los usuarios no deseen exponer la complejidad del espacio de nombres a procesos potencialmente maliciosos o limitar su uso debido a los recursos limitados. La función chroot es mucho más simple (y limitada) que el espacio de nombres de montaje, pero aún puede ser útil. En cuanto a los contenedores, los usuarios de chroot (2) deben cuidar los descriptores de archivos o los datos accesibles por otros medios (por ejemplo, directorio de trabajo actual, FD filtrados, FD pasados, dispositivos, puntos de montaje, etc.). Hay mucha literatura que discute las limitaciones de chroot, y los usuarios de esta función deben conocer las múltiples formas de evitarlo. El uso de chroot (2) con fines de seguridad puede tener sentido si se combina con otras funciones (por ejemplo, usuario dedicado, seccomp, controles de acceso LSM, etc.).
Se podría argumentar que chroot (2) es inútil sin una jerarquía raíz debidamente poblada (es decir, sin / dev y / proc). Sin embargo, hay varios casos de uso que no requieren el proceso de chrooting para crear jerarquías de archivos con archivos especiales ni puntos de montaje, por ejemplo:
* Un proceso de sandboxing en sí mismo, una vez cargadas todas sus bibliotecas, puede que no necesite archivos que no sean archivos normales, o incluso ningún archivo.
* Algunas jerarquías raíz previamente pobladas podrían usarse para crear chroot, proporcionadas, por ejemplo, por entornos de desarrollo o distribuciones personalizadas.
* Los procesos ejecutados en un chroot pueden no requerir acceso a estos archivos especiales (por ejemplo, con tiempos de ejecución mínimos o emulando algunos archivos especiales con una biblioteca LD_PRELOADed o seccomp).
Permitir que una tarea cambie su propio directorio raíz no es una amenaza para el sistema si podemos evitar ataques de delegados confusos, que podrían realizarse mediante la ejecución de binarios similares a SUID. Esto se puede evitar si la tarea de llamada establece PR_SET_NO_NEW_PRIVS en sí misma con prctl (2).
Para afectar solo a esta tarea, la información de su sistema de archivos no debe compartirse con otras tareas, lo que se puede lograr al no pasar CLONE_FS a clone (2).
Seccomp ya utiliza una verificación similar no_new_privs para evitar el mismo tipo de problemas de seguridad. Además, debido a su uso de seguridad y para evitar dar una nueva forma a los atacantes de salir de un chroot (por ejemplo, usando /proc//root), un chroot sin privilegios solo se permite si el nuevo directorio raíz es el mismo o está por debajo del actual.
Esto todavía permite que un proceso use un subconjunto de su sistema de archivos legítimo para hacer chroot y luego reducir aún más su vista del sistema de archivos.
Es posible que este cambio no afecte a los sistemas que se basan en otros modelos de permisos que no sean las capacidades POSIX (por ejemplo, Tomoyo). Ser capaz de usar chroot (2) en tales sistemas puede requerir actualizar sus políticas de seguridad.
El cambio en sí es solo un parche de 64 líneas, pero dado que es un cambio fundamental, pronto veremos lo que piensan los desarrolladores de kernel ascendentes de este cambio liderado por Microsoft para permitir el soporte chroot sin privilegios en Linux.
Fuente: phoronix.com