Quitar el permiso de lectura / escritura / ejecución del usuario

Así que tengo un usuario que puede entrar en /etc y leer files como httpd.conf .

Me gustaría negar que el usuario tenga acceso a ubicaciones críticas como /etc , /var etc.

¿Cuál sería la mejor manera de hacerlo? Realmente no quiero modificar todo mi permiso de carpeta / file solo para un usuario.

Related of "Quitar el permiso de lectura / escritura / ejecución del usuario"

Es posible que desee configurar un aspecto de cárcel chroot en Jailkit .

La cárcel cambia la raíz , como en / , a una nueva ruta.


Como un simple ejemplo como un comienzo.

En primer lugar, lo más probable es que desee tener el directory chroot en una partición separada, de modo que el usuario no pueda llenar su partición del sistema.

Pero en aras de la simplicidad:

  1. Hacer el directory chroot:

     # mkdir /usr/chroot_test # cd /usr/chroot_test 
  2. Hacer directorys del sistema:

     # mkdir bin etc home lib var 
  3. Agregue algunas herramientas básicas:

Aquí uno puede usar ldd para encontrar dependencies.

 # ldd /bin/bash linux-gate.so.1 => (0xb774d000) libtinfo.so.5 => /lib/libtinfo.so.5 (0xb770a000) libdl.so.2 => /lib/libdl.so.2 (0xb7705000) libc.so.6 => /lib/libc.so.6 (0xb755a000) /lib/ld-linux.so.2 (0xb774e000) 

Cópialos en chroot's lib:

 # cp /lib/{libtinfo.so.5,libdl.so.2,libc.so.6,ld-linux.so.2} lib/ 

Ahora ingresa a chroot

 # chroot /usr/chroot_test bash-4.2# ls bash: ls: command not found bash-4.2# pwd / bash-4.2# exit exit 

DE ACUERDO. Trabajos. Agregue algunas herramientas más:

 # sed '/=>/!d;/=>\s*(/d;s/.*=>\s*\([^ ]*\) .*/\1/' < <(ldd /bin/{ls,cat,vi}) | sort -u) ... copy 

Etc.

A continuación, agregue el inicio de session de chroot ( http://kegel.com/crosstool/current/doc/chroot-login-howto.html ).


Pero, como se mencionó, al usar jailkit esto se puede simplificar: http://olivier.sessink.nl/jailkit/howtos_chroot_shell.html .

Puede usar las Listas de control de acceso a files para eliminar permissions de usuarios específicos. El command es setfacl, que establece (crea) una ACL en un file.

Ejemplo de uso:

 root@host:/tmp# date > f1 root@host:/tmp# ls -l f1 -rw-r--r-- 1 root root 30 Mar 28 12:12 f1 root@host:/tmp# setfacl -mu:johan:0 f1 root@host:/tmp# ls -l f1 -rw-r--r--+ 1 root root 30 Mar 28 12:12 f1 

Observe el símbolo + después de los permissions. Te dice que el file tiene un set de ACL. La opción del command setfacl -m le dice que cree / modifique una ACL. El argumento "u: johan: 0" hace que la Entrada de usuario para el usuario "johan" se establezca en "0", que es una abreviatura para el modo de permissions "0 0 0", equivalente a "— — – – "para los sets de permissions" rwx rwx rwx "tradicionales.

 root@host:/tmp# getfacl f1 # file: f1 # owner: root # group: root user::rw- user:johan:--- group::r-- mask::r-- other::r-- root@host:/tmp# cat f1 Thu Mar 28 12:12:07 SAST 2013 root@host:/tmp# exit 

Después de la salida, los commands tienen los permissions del usuario especificado, por ejemplo, "johan"

 johan@host:/tmp> cat f1 cat: f1: Permission denied 

Ahora que he dicho todo eso, ten mucho cuidado . La eliminación indiscriminada de / etc causará todo tipo de fallas y es probable que los usuarios no puedan iniciar session. Muchas funciones del sistema leen, con los permissions del usuario conectado, varios files de configuration en / etc. Sin embargo, es perfectamente aceptable evitar que los usuarios accedan desde files individuales específicos.

Los files que le preocupan están destinados a ser de acceso público. La información realmente confidencial está bloqueada. Sí, Unix es (por layout e historia) un sistema bastante abierto.

Si estás tan preocupado por ese usuario, simplemente encerrarla. Un usuario que no confíe no tiene lugar en sus máquinas.

O consulte con su paranoico, quizás se esté descontrolando.