Ten en cuenta que en las ciencias informáticas un problema puede tener diversas soluciones, por lo tanto nosotros te compartiremos lo mejor y más eficiente.
Solución:
ACL negativas
Puede evitar que un usuario acceda a ciertas partes del sistema de archivos configurando listas de control de acceso. Por ejemplo, para asegurarse de que el usuario abcd
no puede acceder a ningún archivo bajo /home
:
setfacl -m user:abcd:0 /home
Este enfoque es simple, pero debe recordar bloquear el acceso a todo lo que no desea. abcd
para poder acceder.
chroot
Para obtener un control positivo sobre lo que abcd
puede ver, configurar un chroot, es decir, restringir al usuario a un subárbol del sistema de archivos.
Debe crear todos los archivos que el usuario necesita (por ejemplo, mysql
y todas sus dependencias, si desea que el usuario pueda ejecutar mysql
) bajo el chroot. Digamos que el camino al chroot es /home/restricted/abcd
; el mysql
El programa debe estar disponible bajo /home/restricted/abcd
. Un enlace simbólico que apunte fuera del chroot no es bueno porque la búsqueda de enlaces simbólicos se ve afectada por el chroot jail. En Linux, puede hacer un buen uso de los montajes de enlace:
mount --rbind /bin /home/restricted/abcd/bin
mount --rbind /dev /home/restricted/abcd/dev
mount --rbind /etc /home/restricted/abcd/dev
mount --rbind /lib /home/restricted/abcd/lib
mount --rbind /proc /home/restricted/abcd/proc
mount --rbind /sbin /home/restricted/abcd/sbin
mount --rbind /sys /home/restricted/abcd/sys
mount --rbind /usr /home/restricted/abcd/usr
También puede copiar archivos (pero luego deberá asegurarse de que estén actualizados).
Para restringir al usuario al chroot, agregue un ChrootDirectory
directiva a /etc/sshd_config
.
Match User abcd
ChrootDirectory /home/restricted/abcd
Puedes probarlo con:
chroot --userspec=abcd /home/restricted/abcd/ /bin/bash
Marco de seguridad
También puede usar marcos de seguridad como SELinux o AppArmor. En ambos casos, debe escribir una configuración bastante delicada para asegurarse de no dejar ningún agujero.
Deberías usar chroot
. El chroot
El comando cambia el directorio raíz que ven todos los procesos secundarios. Daré un ejemplo para demostrar cómo funciona.
Esto fue escrito en el acto; En realidad, no estoy frente a una máquina UNIX en este momento. En este ejemplo, hay un directorio llamado dir
con tres archivos: a
, b
, c
, y ls
. Los primeros tres son archivos regulares. ls
es un enlace duro a lo real ls
binary para que podamos listar archivos mientras estamos en el chroot.
voy a chroot
en dir
. (Tenga en cuenta que probablemente me estoy olvidando de algunos directorios en el directorio raíz).
Aquí está la configuración, en forma de salida de shell:
$ pwd
/home/alex/test
$ l
dir
$ ls dir
a b c ls
$ ./ls dir # does the same thing
a b c ls
$ ls /
bin boot dev etc home mnt media proc sbin sys usr var
Sin voluntad chroot
en dir
. El /bin/bash
El argumento elige qué proceso debe ejecutarse con el nuevo directorio raíz. Por defecto es /bin/sh
.
$ chroot /bin/bash dir
$ # this prompt is now from a subprocess running in the new root directory
$ PATH=/ ls
a b c ls
$ pwd
/
Ahora salimos de la chroot
:
$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test
Espero que esto ilustre cómo el chroot
el comando funciona. Básicamente lo que tienes que hacer para resolver tu problema es ejecutar un chroot
comando como ese usuario cada vez que inicia sesión. ¿Quizás ponerlo en un script de inicio?
Un enlace fijo a un archivo seguirá funcionando dentro de un chroot
, incluso si no se puede acceder a ese archivo por otros medios (esto funciona porque los enlaces fijos apuntan a inodos, no a rutas). Entonces, para permitir que el usuario acceda, por ejemplo, al mysql
comando, ejecutaría:
ln /usr/bin/mysql /path/to/chroot/target