Otorgue al usuario acceso de lectura / escritura a un solo directorio

Estoy ejecutando un servidor y necesito dar acceso de lectura / escritura a un directorio particular a un solo usuario. He intentado lo siguiente:

sudo adduser abcd
sudo groupadd abcdefg
chown -R .abcdefg /var/www/allowfolder
chmod -R g+rw /var/www/allowfolder
usermod -a -G comments abcd

Lo anterior parece funcionar, sin embargo, le da al usuario acceso de solo lectura al resto del servidor.

¿Cómo puedo configurar permisos para que el usuario solo pueda leer y escribir en una carpeta en particular? El usuario también debería poder ejecutar programas como mysql.

permissions files account-restrictions

— Manishearth
fuente

La respuesta corta: usa un chroot.

— Chris Down

@Chris ¿Le gustaría elaborar eso en una respuesta? Manish y yo hemos estado luchando con esto y parece que no podemos hacer que funcione.

— Deshacer el

¿Dónde se ubicaría el mysqlprograma? El usuario debe poder leerlo, y todas las bibliotecas y archivos de datos que necesita.

— Gilles 'SO- deja de ser malvado'

@Gilles Hmm. Es una instalación estándar de mysql de apt-get, por lo que puedo decir (no es mi sistema, es Deshacer).

— Manishearth

Respuestas:

LCA negativas

Puede evitar que un usuario acceda a ciertas partes del sistema de archivos estableciendo listas de control de acceso . Por ejemplo, para garantizar que el usuario abcdno pueda acceder a ningún archivo en /home:

setfacl -m user:abcd:0 /home

Este enfoque es simple, pero debe recordar bloquear el acceso a todo a lo que no desea abcdpoder acceder.

Chroot

Para obtener un control positivo sobre lo que abcdpuede ver, configure un chroot , es decir, restrinja al usuario a un subárbol del sistema de archivos.

Debe crear todos los archivos que necesita el usuario (por ejemplo, mysqly 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 mysqlprograma debe estar disponible en /home/restricted/abcd. Un enlace simbólico que apunta fuera del chroot no es bueno porque la búsqueda del enlace simbólico se ve afectada por la cárcel chroot. 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 una ChrootDirectorydirectiva 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.

— Gilles 'SO- deja de ser malvado'
fuente

¿No podría ser una forma mucho más fácil de otorgar permisos de lectura y escritura a un directorio en particular mediante la creación de grupos? Por ejemplo, podría crear un nuevo grupo y usar chown para hacer que el propietario del grupo del directorio sea el grupo que se creó y agregar el usuario al grupo. Por último, otorgue al directorio permisos de lectura y escritura para grupos.

— Qasim

@Qasim Eso requiere que todos los archivos tengan sus permisos y propiedad establecidos como se desee. Hay tantas cosas que pueden salir mal (archivos copiados de otro lugar o extraídos de un archivo con sus permisos preservados, archivos que deben pertenecer a otro grupo, archivos que no deberían ser legibles en grupo, usuarios que cometen errores o pueden ' No se moleste en asegurarse de que la accesibilidad del grupo se mantenga como se desea ...) que los grupos realmente no resuelven este problema.

— Gilles 'SO- deja de ser malvado'

Quiero decir que no veo cómo los archivos tendrían que tener sus propios permisos si los permisos de grupo en el directorio se configuraran de manera que ningún usuario pudiera "cd" en el directorio o "ls" el directorio.

— Qasim

@Qasim Todos los archivos /var/www/allowfoldery sus subdirectorios deben ser accesibles, no solo ellos /var/www/allowfoldermismos. Y a la inversa, otros archivos no deben ser accesibles. De hecho, una solución basada únicamente en permisos de archivos y ACL no puede cumplir completamente los requisitos: al menos permitiría al usuario probar si existe un nombre dado /var/www, ya que necesitan tener permiso x /var/wwwpara acceder /var/www/allowfolder.

— Gilles 'SO- deja de ser malvado'

Oh ok, ya veo, pero si excluimos el directorio / var de esto y digamos que estamos hablando de un directorio normal en el directorio / home / user.

— Qasim

Debe utilizar chroot. El chrootcomando 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 dircon tres archivos: a, b, c, y ls. Los primeros tres son archivos regulares. lses un enlace directo al lsbinario real para que podamos enumerar archivos mientras estamos en el chroot.

Voy a chrootdentro dir. (Tenga en cuenta que probablemente estoy olvidando 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

Ahora voy a chrootentrar dir. El /bin/bashargumento elige qué proceso se debe ejecutar 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 chroot:

$ exit
$ # this prompt is now from the original bash process, from before the chroot
$ pwd
/home/alex/test

Espero que esto ilustra cómo funciona el chrootcomando. Básicamente, lo que tiene que hacer para resolver su problema es ejecutar un chrootcomando como ese usuario cada vez que inicie sesión. ¿Quizás ponerlo en un script de inicio?

Un enlace fijo a un archivo continuará funcionando dentro de un chrootarchivo, incluso si no se puede acceder a ese archivo por otros medios (esto funciona porque los enlaces directos apuntan a inodes, no a rutas). Entonces, para permitir que el usuario acceda, por ejemplo, al mysqlcomando, debe ejecutar:

ln /usr/bin/mysql /path/to/chroot/target

— Strugee
fuente

¿Pero esto no me obligaría a configurar un entorno chroot completo con todos los enlaces simbólicos? ¿No sería más fácil ejecutar un comando para que el nuevo usuario no tenga acceso a los otros directorios, pero los programas como apache no pierdan el acceso a ellos?

— Manishearth

Básicamente, ¿hay alguna forma (a través de chmod) de hacer que un usuario pierda el acceso de lectura al resto de los archivos fs sin afectar el acceso de otros usuarios?

— Manishearth

@Manishearth no hay una manera simple de hacerlo chmod. cuando dices "no sería más fácil ejecutar un comando ... no pierdas el acceso a ellos", ese comando es chroot. si explica lo que quiere decir con "un entorno chroot completo", o por qué esto sería un problema, tal vez lo entienda mejor. (Observe que puede dar acceso a todos los archivos ejecutables con una oneliner: ln /bin/* /path/to/chroot/target)

— strugee

@Manishearth, si mi ejemplo no tiene sentido, te animo a que juegues chrootcontigo mismo o me hagas saber lo que no tiene sentido. aún mejor, haz las dos cosas. (y lea las páginas de manual.)

— strugee

@Manishearth si esta respuesta te ayudó lo suficiente como para llevarte a la respuesta, deberías considerar aceptarla.

— Strugee