Preguntas más similares con más respuestas que merecen atención:
NOTA: Algunas de las respuestas apuntan a soluciones específicas que aún no se mencionan aquí.
En realidad, hay bastantes herramientas de encarcelamiento con implementación diferente, pero muchas de ellas no son seguras por diseño (como fakeroot, LD_PRELOADbasadas en) o no están completas (como fakeroot-ng, ptracebasadas en), o requerirían root ( chrooto se plashmencionan en fakechroot etiqueta de advertencia ).
Estos son solo ejemplos; Pensé en enumerarlos todos lado a lado, con indicación de estas 2 características ("¿se puede confiar?", "¿Requiere root para configurar?"), Tal vez en implementaciones de virtualización a nivel de sistema operativo .
En general, las respuestas allí cubren la gama completa de posibilidades descritas y aún más:
máquinas virtuales / SO
extensión del kernel (como SELinux)
- (mencionado en los comentarios aquí),
chroot
Ayudantes basados en Chroot (que, sin embargo, deben establecerse como root de UID, porque chrootrequieren root; o tal vez chrootpodrían funcionar en un espacio de nombres aislado, ver a continuación):
[para contar un poco más sobre ellos!]
Herramientas de aislamiento basadas en chroot conocidas:
- hasher con sus
hsh-runy hsh-shellcomandos. ( Hasher fue diseñado para crear software de manera segura y repetible).
- Schroot mencionado en otra respuesta
- ...
traza
Otra solución de aislamiento confiable (además de una seccompbasada en la base ) sería la intercepción completa de syscall ptrace, como se explica en la página de manual para fakeroot-ng:
A diferencia de las implementaciones anteriores, fakeroot-ng usa una tecnología que no deja al proceso rastreado ninguna opción con respecto a si usará o no los "servicios" de fakeroot-ng. Compilar un programa estáticamente, llamar directamente al kernel y manipular el propio espacio de direcciones son todas técnicas que pueden usarse trivialmente para evitar el control basado en LD_PRELOAD sobre un proceso y no se aplican a fakeroot-ng. En teoría, es posible moldear fakeroot-ng de tal manera que tenga un control total sobre el proceso trazado.
Si bien es teóricamente posible, no se ha hecho. Fakeroot-ng asume ciertas suposiciones de "buen comportamiento" sobre el proceso que se está rastreando, y un proceso que rompa esas suposiciones puede, si no escapa totalmente, al menos eludir parte del entorno "falso" impuesto por fakeroot- ng. Como tal, se le advierte fuertemente contra el uso de fakeroot-ng como herramienta de seguridad. Los informes de errores que afirman que un proceso puede escapar deliberadamente (en lugar de inadvertidamente) el control de fake-root-ng se cerrará como "no es un error" o se marcará como de baja prioridad.
Es posible que esta política sea repensada en el futuro. Por el momento, sin embargo, has sido advertido.
Aún así, como puede leerlo, en fakeroot-ngsí mismo no está diseñado para este propósito.
(Por cierto, me pregunto por qué han elegido utilizar el seccompenfoque basado en Chromium en lugar de un enfoque ptracebasado en ...)
De las herramientas no mencionadas anteriormente, he señalado a Geordi por mí mismo, porque me gustó que el programa de control esté escrito en Haskell.
Herramientas de aislamiento basadas en ptrace conocidas:
seccomp
Una forma conocida de lograr el aislamiento es a través del enfoque de seccomp sandboxing utilizado en Google Chromium . Pero este enfoque supone que usted escribe un asistente que procesará algunos (los permitidos) del acceso al archivo "interceptado" y otras llamadas al sistema; y también, por supuesto, hacer un esfuerzo para "interceptar" las llamadas al sistema y redirigirlas al asistente (tal vez, incluso significaría reemplazar las llamadas al sistema interceptadas en el código del proceso controlado; por lo tanto, no suena para ser bastante simple; si está interesado, será mejor que lea los detalles en lugar de solo mi respuesta).
Más información relacionada (de Wikipedia):
(El último elemento parece ser interesante si uno está buscando una seccompsolución de base general fuera de Chromium. También hay una publicación de blog que vale la pena leer del autor de "seccomp-nurse": ¿ SECCOMP como una solución de Sandboxing?. )
La ilustración de este enfoque del proyecto "seccomp-nurse" :
¿Una seccomp "flexible" posible en el futuro de Linux?
En 2009, también aparecían sugerencias para parchear el kernel de Linux para que haya más flexibilidad en el seccompmodo, de modo que "se puedan evitar muchas de las acrobacias que necesitamos actualmente". ("Acrobacias" se refiere a las complicaciones de escribir un ayudante que tiene que ejecutar muchas llamadas de sistema posiblemente inocentes en nombre del proceso encarcelado y de sustituir las llamadas de sistema posiblemente inocentes en el proceso encarcelado). Un artículo de LWN escribió a este punto:
Una sugerencia que surgió fue agregar un nuevo "modo" a seccomp. La API fue diseñada con la idea de que diferentes aplicaciones podrían tener diferentes requisitos de seguridad; incluye un valor de "modo" que especifica las restricciones que deben establecerse. Solo se ha implementado el modo original, pero ciertamente se pueden agregar otros. La creación de un nuevo modo que permitiera al proceso de inicio especificar qué llamadas al sistema se permitirían haría que la instalación sea más útil para situaciones como el entorno limitado de Chrome.
Adam Langley (también de Google) ha publicado un parche que hace exactamente eso. La nueva implementación del "modo 2" acepta una máscara de bits que describe qué llamadas del sistema son accesibles. Si uno de ellos es prctl (), entonces el código de espacio aislado puede restringir aún más sus propias llamadas al sistema (pero no puede restaurar el acceso a las llamadas del sistema que han sido denegadas). En total, parece una solución razonable que podría facilitar la vida de los desarrolladores de sandbox.
Dicho esto, es posible que este código nunca se fusione porque la discusión se ha trasladado a otras posibilidades.
Este "seccomp flexible" acercaría las posibilidades de Linux a proporcionar la función deseada en el sistema operativo, sin la necesidad de escribir ayudantes tan complicados.
(Una publicación de blog con básicamente el mismo contenido que esta respuesta: http://geofft.mit.edu/blog/sipb/33 .)
espacios de nombres ( unshare)
Aislar a través de espacios de nombres ( unsharesoluciones basadas ), no mencionados aquí, por ejemplo, compartir puntos de montaje (¿combinados con FUSE?) Podría ser parte de una solución de trabajo para que desee limitar el acceso al sistema de archivos de sus procesos no confiables.
Más sobre los espacios de nombres, ahora, ya que su implementación se ha completado (esta técnica de aislamiento también se conoce con el nombre de "Contenedores Linux" o "LXC" , ¿no es así?):
"Uno de los objetivos generales de los espacios de nombres es apoyar la implementación de contenedores, una herramienta para la virtualización ligera (así como para otros fines)" .
Incluso es posible crear un nuevo espacio de nombres de usuario, de modo que "un proceso pueda tener una ID de usuario normal sin privilegios fuera de un espacio de nombres de usuario y al mismo tiempo tener una ID de usuario 0 dentro del espacio de nombres. Esto significa que el proceso tiene todos los privilegios de root para operaciones dentro del espacio de nombres de usuario, pero no tiene privilegios para operaciones fuera del espacio de nombres ".
Para ver los comandos de trabajo reales para hacer esto, vea las respuestas en:
y programación / compilación especial de espacio de usuario
Pero bueno, por supuesto, las garantías de "cárcel" deseadas son implementables mediante la programación en el espacio del usuario ( sin soporte adicional para esta función desde el sistema operativo ; quizás es por eso que esta función no se ha incluido en primer lugar en el diseño de sistemas operativos) ); con más o menos complicaciones
El mencionado ptrace- o seccompcaja de arena basado puede ser visto como algunas variantes de la aplicación de las garantías por escrito una caja de arena-helper que controlar sus otros procesos, que serían tratados como "cajas negras", arbitraria programas Unix.
Otro enfoque podría ser usar técnicas de programación que puedan preocuparse por los efectos que deben ser rechazados. (Debes ser tú quien escribe los programas; ya no son cajas negras). Por mencionar uno, usar un lenguaje de programación puro (que te obligaría a programar sin efectos secundarios) como Haskell simplemente hará que todos los efectos de programa explícito, por lo que el programador puede asegurarse fácilmente de que no habrá efectos no permitidos.
Supongo que hay instalaciones de sandboxing disponibles para aquellos que programan en algún otro lenguaje, por ejemplo, Java.
Algunas páginas que acumulan información sobre este tema también fueron señaladas en las respuestas allí: