Cómo deshabilitar la creación de socket para un proceso de Linux, para sandboxing?

Question

Estoy considerando varias opciones para sandboxing un proceso de Linux. El uso de clone() con CLONE_NEWNET (etc.) es una de las opciones. CLONE_NEWNET asegura que el proceso de espacio aislado no puede hacer o aceptar conexiones de red reales. Pero me gustaría deshabilitar los sockets por completo para ese proceso, incluso bind() ing en cualquier puerto en 0.0.0.0, y enlazar a un socket doman Unix (incluso anónimo). Me gustaría hacer esto para evitar que el proceso use demasiados recursos del kernel vinculando a miles de puertos. ¿Cómo puedo hacer eso?

En general, estoy interesado en muchos enfoques de sandboxing (es decir, los proporcionados por el kernel de Linux y los forzados por ptrace()), pero en esta pregunta solo me interesa el aspecto de creación de socket de los enfoques de sandboxing (si sugiere un enfoque de espacio aislado, también explique cómo evitar la creación de socket con él), y no estoy interesado en enfoques que necesiten parcheo del kernel o que impliquen cargar un módulo kernel que no es parte del paquete kernel por defecto Ubuntu Lucid , o que afectaría todos los procesos en el sistema.

Answer 1

ptrace parece ser la herramienta más obvia, pero aparte de eso ...

util-linux [-ng] tiene un comando unshare, que utiliza clone/unshare interfaces del kernel. Si ejecuta el nuevo proceso a través de unshare -n (o clone(CLONE_NEWNET)), los sockets de red que crea están en un espacio de nombre diferente. Eso no resuelve el problema de los recursos del kernel, pero lo hace en el proceso de sandbox.

El núcleo de Linux también soporta seccomp, un modo entraron con prctl(PR_SET_SECCOMP, 1) que impide el proceso (así, hilo, en realidad) de llamar a cualquier llamadas al sistema que no sea read, write, exit y sigreturn. Es un entorno limitado bastante efectivo pero difícil de usar con código no modificado.

Puede definir un dominio SELinux que no permita socket/bind/etc. llamadas, y realizar una transición dinámica en ese tipo. Esto (obviamente) requiere un sistema con una política de SELinux de aplicación activa. (Posiblemente cosas similares son posibles con AppArmor y TOMOYO, pero no estoy muy familiarizado con ninguno de ellos.)

Answer 2

Eche un vistazo a systrace - no se limita a enchufes, sino a un generador/ejecutor de políticas syscall genérico. Cita:

El puerto GNU/Linux ha finalizado y el parche del kernel es mantenido activamente por Marius Eriksen. Se puede ejecutar sin cambios de kernel usando el back-end ptrace.

Disclamer - Nunca lo intenté en Linux.

Answer 3

Pruebe seccomp (consulte la página de manual de prctl), puede limitar su proceso para que solo acceda a los sockets que se dejaron abiertos en el momento en que se realizó la llamada de prctl.

Answer 4

que podría estar interesado con "sydbox" caja de arena o "pinktrace" biblioteca:

http://www.diigo.com/user/wierzowiecki/sydbox

Answer 5

Si su objetivo principal es limitar el número de tomas que se abren mediante algún proceso benigno P aplicado a entradas benignas, entonces setrlimit(RLIMIT_NOFILE, ...) hará aproximadamente lo que usted desee.

Sin embargo, si se asume que P es malicioso en lugar de benigno o si está buscando una garantía sólida sobre cómo se comportará P frente a las entradas potencialmente maliciosas, entonces probablemente no tenga suerte: es decir, en Lo mejor, con las herramientas disponibles hoy, puedes crear una carrera de obstáculos para los atacantes.

(Dicho esto, si una carrera de obstáculos que funciona para usted, entonces es posible conseguir algunas más buenas ideas por hurgando por aquí en sandboxing.org o enviando sus preguntas a la gente amable en sandboxing-talk@lists.sandboxing.org.)