Restrinja a un usuario de Linux a los archivos que posee

Imagine una configuración de servidor de una empresa de alojamiento web compartida donde varios (~ 100) clientes tienen acceso de shell a un solo servidor.

Una gran cantidad de "software" web recomienda chmod files 0777 . Estoy nervioso porque nuestros clientes sigan imprudentemente estos tutoriales, abriendo sus archivos a nuestros otros clientes. (¡Ciertamente no lo estoy usando cmod 0777innecesariamente!) ¿Existe un método para asegurar que los clientes solo puedan acceder a sus propios archivos y evitar que accedan a archivos legibles por el mundo de otros usuarios?

Miré en AppArmor , pero eso está muy estrechamente vinculado a un proceso, que parece fallar en ese entorno.

Ponga un directorio restringido e inmutable entre el mundo exterior y los archivos protegidos, p. Ej.

/
 ├─ bin
 ├─ home
 │  └─ joe <===== restricted and immutable
 │     └─ joe <== regular home directory

o /home/joe/restricted/public_html.

Restringido significa que solo el usuario y quizás el servidor web pueden leerlo (por ejemplo, modos 0700/ 0750o algunas ACL ).

La inmutabilidad se puede hacer con chattr +io cambiando la propiedad a algo así root:joe.

Una manera fácil de crear esa jerarquía en Ubuntu sería la de editar /etc/adduser.confy conjunto GROUPHOMESa yes.

Hay una opción que es posible que desee considerar (dependiendo de cuánto trabajo quiera hacer para eso).

Como otros ya publicaron, "normalmente" no puede evitar que alguien con acceso de shell lea archivos legibles en todo el mundo.

Sin embargo, podría agruparlos en su propio hogar, básicamente limitando el acceso de shell a, primero, solo el directorio raíz que desee (también conocido como el directorio de inicio) y, en segundo lugar, evitar que los usuarios ejecuten todo lo que no desea que ejecuten.

Hice un enfoque similar cuando tuve un usuario para tener acceso a los archivos web, pero no quería que él viera otros archivos fuera de la carpeta web.

Esto tenía mucha sobrecarga, era un desastre para configurar, y cada vez que actualizaba algo, se rompía.

Pero por hoy creo que podría lograrlo bastante fácil con la opción de chroot OpenSSH :

WikiBooks OpenSSH

He descubierto que las listas de control de acceso POSIX le permiten a usted, como administrador del sistema, proteger a sus usuarios de lo peor de su propia ignorancia, anulando el permiso regular del sistema de archivos de otro grupo de usuarios, sin mucha oportunidad de romper algo crucial .

Pueden ser especialmente útiles si, por ejemplo, (fi) necesita que los directorios principales sean accesibles mundialmente porque el contenido web debe ser accesible para apache ~/public_html/. (Aunque con las ACL ahora puede hacer lo contrario, eliminar el acceso para todos y usar una ACL efectiva específica para el usuario de apache).

Sí, un usuario bien informado puede eliminarlos / anularlos nuevamente, son lo suficientemente poco comunes como para que sea poco probable, y aquellos usuarios que generalmente no son los que convenientemente pueden hacerlo chmod -R 777 ~/, ¿verdad?

Necesita montar el sistema de archivos con la aclopción de montaje:

 mount -o remount,acl /home

En muchas distribuciones, el valor predeterminado es crear grupos de usuarios, cada usuario tiene su grupo primario y he configurado a todos los usuarios en un grupo secundario con el nombre poco imaginativo de users.

Usar ACL ahora es trivial para evitar que otros usuarios accedan a los directorios de inicio:

Antes de:

 chmod 0777 /home/user* 

 ls -l /home/user*
 drwxrwxrwx.  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx.  2 user2  user2  4096 Jul 11 15:24 user2

Ahora configure los permisos de directorio efectivos para los miembros del usersgrupo para 0no leer, escribir o acceder:

 setfacl setfacl -m g:users:0 /home/user*

 ls -l 
 drwxrwxrwx+  2 user1  user1  4096 Jul 11 15:40 user1
 drwxrwxrwx+  2 user2  user2  4096 Jul 11 15:24 user2

El +signo denota la presencia de configuraciones de ACL allí. Y el getfaclpuede confirmar que:

getfacl /home/user1
getfacl: Removing leading '/' from absolute path names
# file: home/user1
# owner: user1
# group: user1
user::rwx
group::rwx
group:users:---
mask::rwx
other::rwx

El group:users:---programa muestra que ese grupo efectivamente no tiene derecho de acceso, a pesar de los permisos regulares para otro serother::rwx

Y probando como usuario1:

[user1@access ~]$ ls -la /home/user2
ls: cannot open directory /home/user2: Permission denied

Una segunda solución común en sistemas compartidos es hacer que el automontador monte los directorios de inicio a pedido en un servidor dedicado al acceso de shell. Eso está lejos de ser una prueba infalible, pero generalmente solo unos pocos usuarios iniciarán sesión simultáneamente, lo que significa que solo los directorios principales de esos usuarios son visibles y accesibles.

Linux Containers (LXC) podría ser la mejor combinación de chroot y sistema separado.

1. Se parecen más a un chroot avanzado, no a la virtualización, pero podría combinar diferentes sistemas operativos en un servidor.

2. Puede proporcionarle a un usuario un sistema operativo completo y hacerlo allí, de modo que cuando el usuario inicia sesión, vaya a su contenedor. Y también puede limitar el uso del procesador y la memoria allí.

Stéphane Graber, el autor de LXC, tiene un buen tutorial para ayudarlo a comenzar.

Por ejemplo, si desea que el usuario tenga acceso solo a su propio homedirectorio, debe hacer lo siguiente:

cd /home
sudo chmod 700 *

Ahora /home/usernamesolo es visible para su propietario. Para que sea el valor predeterminado para todos los usuarios nuevos, edite /etc/adduser.confy establezca DIR_MODEen 0700lugar del 0755valor predeterminado.

Por supuesto, si desea modificar el DIR_MODE predeterminado, depende de su distribución, la que publiqué funciona Ubuntu.

editar

Como @Dani_l mencionó correctamente, esta respuesta es correcta para que NO sean legibles en todo el mundo.

Solo para ser pedante - No, no lo hay.
@Marek dio una respuesta correcta , pero su pregunta es incorrecta: no puede evitar que nadie acceda a archivos "legibles en todo el mundo".
O son legibles por el mundo o no lo son. La respuesta de @ Marek es correcta al hacer que NO sean legibles para el mundo.

No veo ninguna mención del 'caparazón restringido' en las respuestas dadas hasta ahora.

ln / bin / bash / bin / rbash

Establezca esto como su shell de inicio de sesión.

Si el servidor web se ejecuta como el mismo usuario y grupo para cada dominio alojado, es difícil (si no imposible) hacer que la configuración sea segura.

Desea que ciertos archivos sean accesibles tanto para el usuario como para el servidor web, pero no para otros usuarios. Pero tan pronto como el servidor web pueda acceder a ellos, otro usuario podría leerlos poniendo un enlace simbólico al archivo dentro de su propio sitio web.

Si puede hacer que cada sitio web se ejecute como un usuario separado, entonces se vuelve bastante simple. Cada cliente ahora tendrá dos usuarios en el sistema, uno para el servidor web y otro para el acceso de shell.

Cree un grupo que contenga estos dos usuarios. Ahora cree un directorio con ese grupo y usuario root. Ese directorio debe tener permisos 750, lo que significa que la raíz tiene acceso completo y el grupo tiene acceso de lectura y ejecución. Dentro de ese directorio puede crear directorios de inicio para cada uno de los dos usuarios. Esto significa que el directorio de inicio del usuario ya no tendrá el formulario /home/username, sino algo con al menos un componente de directorio más. Esto no es un problema, nada requiere que los directorios principales se nombren de acuerdo con esa convención específica.

Hacer que los sitios web se ejecuten con diferentes usuarios y grupos puede ser complicado, si está utilizando vhosts basados ​​en nombres. Si resulta que solo puede hacer que la separación funcione con vhosts basados ​​en IP, y no tiene suficientes IP para cada sitio, puede alojar cada sitio web en una dirección IPv6 y colocar un proxy inverso para todos ellos en un Dirección IPv4