Felipe, parte de este staff, nos ha hecho el favor de crear este escrito ya que domina a la perfección el tema.
Solución:
Solución 1:
En Linux, la llamada al sistema chroot(2) solo puede ser realizada por un proceso que tenga privilegios. La capacidad que necesita el proceso es CAP_SYS_CHROOT.
La razón por la que no puede hacer chroot como usuario es bastante simple. Suponga que tiene un programa setuid como sudo que verifica /etc/sudoers si tiene permiso para hacer algo. Ahora póngalo en un chroot chroot con su propio /etc/sudoers. De repente tienes una escalada de privilegios instantánea.
Es posible diseñar un programa para chroot y ejecutarlo como un proceso setuid, pero esto generalmente se considera un mal diseño. La seguridad extra del chroot no motiva el temas de seguridad con el setuido.
Solución 2:
@imz–IvanZakharyaschev comenta sobre la respuesta de pehrs que puede ser posible con la introducción de espacios de nombres, pero esto no se ha probado ni publicado como respuesta. Sí, eso hace posible que un usuario que no sea root use chroot.
Dado un enlace estático dashy un enlace estático busyboxy una carrera bash shell ejecutándose como no root:
$ mkdir root
$ cp /path/to/dash root
$ cp /path/to/busybox root
$ unshare -r bash -c 'chroot root /dash -c "/busybox ls -al /"'
total 2700
drwxr-xr-x 2 0 0 4096 Dec 2 19:16 .
drwxr-xr-x 2 0 0 4096 Dec 2 19:16 ..
drwxr-xr-x 1 0 0 1905240 Dec 2 19:15 busybox
drwxr-xr-x 1 0 0 847704 Dec 2 19:15 dash
El ID de usuario raíz en ese espacio de nombres se asigna al ID de usuario no raíz fuera de ese espacio de nombres, y viceversa, por lo que el sistema muestra los archivos que pertenecen al usuario actual como propiedad del ID de usuario 0. Un ls -al rootsin que unsharelos muestra como propiedad del usuario actual.
Nota: es bien sabido que los procesos que son capaces de utilizar chrootson capaces de salir de un chroot. Ya que unshare -r concedería chroot permisos a un usuario ordinario, sería un riesgo de seguridad si eso se permitiera dentro de un chroot ambiente. De hecho, no está permitido, y falla con:
dejar de compartir: error al dejar de compartir: operación no permitida
que coincide con la documentación de unshare(2):
EPERM (desde Linux 3.9)
CLONE_NUEVOUSUARIO se especificó en banderas y la persona que llama está en un entorno chroot (es decir, el directorio raíz de la persona que llama no coincide con el directorio raíz del espacio de nombres de montaje en el que reside).
Solución 3:
En estos días, desea buscar LXC (Linux Containers) en lugar de chroot/BSD jail. Está en algún lugar entre un chroot y una máquina virtual, lo que le brinda mucho control de seguridad y capacidad de configuración general. Creo que todo lo que necesita para ejecutarlo como usuario es ser miembro del grupo que posee los archivos/dispositivos necesarios, pero también puede haber capacidades/permisos del sistema involucrados. De cualquier manera, debería ser muy factible, ya que LXC es bastante reciente, mucho después de que SELinux, etc., se agregara al kernel de Linux.
Además, tenga en cuenta que solo puede escribir secuencias de comandos como root pero otorgar a los usuarios un permiso seguro para ejecutar esas secuencias de comandos (sin contraseña, si lo desea, pero asegúrese de que la secuencia de comandos sea segura) usando sudo.
Solución 4:
La combinación de fakeroot / fakechroot brinda un simulacro de chroot para necesidades simples, como producir archivos tar donde los archivos parecen ser propiedad de root. La página de manual de Fakechroot es http://linux.die.net/man/1/fakechroot.
Sin embargo, no obtiene ningún permiso nuevo, pero si posee un directorio (por ejemplo, una distribución falsa) antes de invocar
fakechroot fakeroot chroot ~/fake-distro some-command
ahora busca algún comando como si fueras root y fueras dueño de todo dentro de fake-distro.