
Estoy buscando en el /proc
directorio y, como usuario, no puedo enumerar un directorio aunque muestra que el usuario es el propietario.
¿Por qué y cómo sucede esto?
Por ejemplo, en ls -l /proc/2323/map_files
él dice ls: reading directory '.': Permission denied
. Pero el dueño es claramente usuario. El usuario puede ingresar al directorio pero no ls
. Sin embargo, hacer esto como root está bien.
Historia de fondo agregada:
Actualmente, el proceso utiliza firejail, que es un binario setuid, para colocar mayúsculas y espacios de nombres para aislar Firefox. Sin Firejail, todo funciona como se esperaba, es decir, el usuario puede hacerlo ls map_files
, pero con Firejail, el directorio map_files no puede estar ls
en manos del usuario, aunque cd
está bien. No es un problema de permisos, ya que el directorio es legible por el usuario y los archivos, que son enlaces simbólicos a archivos .so, también muestran u+r.
Respuesta1
Puede eliminar el permiso de lectura de un archivo de su propiedad y luego ya no podrá leerlo.
$ echo hello >foo
$ chmod u=w,go+r foo
$ ls -l foo
--w-rw-r-- 1 gilles gilles 6 Oct 20 15:13 foo
$ cat foo
cat: foo: Permission denied
Esto no es útil por motivos de seguridad ya que el propietario puede cambiar los permisos del archivo en cualquier momento. Es solo una consecuencia de cómo funcionan los permisos.
Sin embargo, esto no explica lo que estás viendo en /proc
. /proc
es un sistema de archivos algo especial. Con los sistemas de archivos "ordinarios", cuando un proceso abre un archivo (o enumera un directorio, o lee el destino de un enlace simbólico), el núcleo verifica las credenciales del proceso (es decir, con qué usuario se está ejecutando, etc.), lee los permisos del archivo y comprueba si las credenciales dan acceso al archivo. Pero /proc
no funciona así. El kernel aplica comprobaciones específicas, que son diferentes para distintos archivos en formato /proc
. Por otra parte, cuando un proceso lista un directorio, el kernel genera permisos que son una aproximación de las comprobaciones realizadas al abrir un archivo.
En particular, si un proceso se está ejecutando o se ha estado ejecutando con credenciales elevadas (normalmentesetuid o setgid, parte de la información /proc
ya no es accesible para el usuario, solo para root. Esto no se refleja en los permisos. Por ejemplo, considere un proceso que ejecuta setgid. Este proceso tendrá todos los archivos /proc
propiedad del usuario esperado y los permisos serán los mismos que para los procesos sin privilegios. Sin embargo, debido a que el proceso puede haber tenido acceso a información confidencial mientras tenía privilegios de grupo adicionales, el kernel ya no permite al usuario realizar operaciones que podrían filtrar esta información. Y así, por ejemplo, el usuario no puede ver a qué /proc/$pid/cwd
apunta, en caso de que el proceso haya cambiado a un directorio al que el usuario normalmente no puede acceder. El usuario no puede volcar la memoria del proceso a través de /proc/$pid/mem
. El usuario no puede ver los mapas de memoria del proceso /proc/$pid/map*
en caso de que reflejen información confidencial (y también para mantenerASLReficaz). Etcétera.
Respuesta2
Configurar un archivo propiedad del usuario, pero no legible por el mismo usuario, es realmente muy fácil:
chmod u-r file
Si hace eso, la única forma de leer el archivo sería elevar sus privilegios o devolver el indicador de lectura ( u+r
).
Lo mismo ocurre con los directorios. Elimine la marca de lectura del usuario y el propietario del directorio no podrá hacerlo ls
. Elimine la marca ejecutable del directorio ( u-x
) y el propietario perderá la capacidad de cd
acceder a ese directorio.
Al mismo tiempo, otras personas ( o+r
y o+x
) pueden acceder a estos archivos y directorios. Y, por supuesto, siempre son accesibles medianteraízque ignora las banderas de permiso.
Los directorios y archivos en /proc
el directorio representan procesos, subprocesos y objetos de memoria compartida. Sus permisos los establece la aplicación cuando crea el hilo/memoria compartida. Por lo tanto, no responden a chmod
la herramienta e intentar cambiar el permiso es una forma segura de interrumpir la aplicación en ejecución. Pero ls
aún cd
obedecer las banderas de permiso en los objetos en /proc
. Entonces, si realmente necesitas leer algo allí, debes elevarte araíz.
Respuesta3
Es causado por los derechos de los usuarios.
ejemplo:
[~] whoami
mm
[~] mkdir test
[~] echo "Hello World" > test/hello.txt
[~] ls -ld test
drwxr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] chmod 111 test
[~] ls -ld test
d--x--x--x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
ls: cannot open directory 'test': Permission denied
[~, ERR:2] cat test/hello.txt
Hello World
[~] chmod 555 test
[~] ls -ld test
dr-xr-xr-x 2 mm mm 4,0K 20. Okt 14:20 test
[~] ls test
hello.txt
Los derechos de carpeta difieren de los derechos de archivo. Esto x
significa que puede acceder a la carpeta pero no puede mirarla. Para buscar en esa carpeta, también necesitarás r
. Y por supuesto w
significa que puedes escribir en esa carpeta.