¿Cómo crea Firejail su lista negra predeterminada?

¿Cómo crea Firejail su lista negra predeterminada?

Cuando comienzo firejail, veo mi directorio de inicio completo. Cuando empiezo firejail --whitelist=~/something, lo veo sólo somethingen mi casa. Ahora me gustaría restringir más acceso al sistema. Por ejemplo, puedo agregar --blacklist=/mediay funciona como se esperaba.

Pero, ¿cómo determina el comportamiento predeterminado que /home/OTHERUSERlos /home/*archivos de la lista blanca estén ocultos? No veo una regla coincidente en /etc/firejail/*.

¿Y son posibles los subdirectorios permitidos? Por ejemplo, --blacklist=/media --whitelist=/media/datano funciona como se esperaba, incluso cuando la página de manual indica que la lista blanca anula otras opciones como --read-only.

¿Están estas reglas codificadas en binario? Si no, ¿qué regla hace estas cosas?

Un ejemplo de lo que me gustaría tener. Reglas básicas:

  1. Casa vacía, excepto por las cosas que figuran en el perfil.
  2. Lista negra/media/data
  3. Permitir enlace simbólico ~/apps ->/media/data/appsde solo lectura.
  4. Permitir /media/data/apps(si es necesario) solo lectura.

1, 2 están funcionando, 3 solo funciona con 4 (probablemente esté bien), pero anular el acceso de lectura para un subdirectorio de un directorio prohibido no funciona.

Parece un poco contrario a la intuición que debería funcionar, pero en la capa del sistema de archivos mkdir -p foo/bar;chmod 111 foo;ls foo/bar/(donde 111significa que no hay permiso de lectura (lista de directorios) en foo, pero solo funciona el bit ejecutable (ingresar subdirectorios), incluso cuando ls foo/falla.

El escenario extendido no permitiría todo excepto una lista blanca (perfil + /usr, /bin, /lib, etc.). Otra cosa que no parece posible sin root (y luego la aplicación se ejecuta como root) es reemplazar, por ejemplo, /etc/passwd con uno que no contenga usuarios, que no deberían conocerse en la cárcel. /etccontiene una gran cantidad de datos legibles, que deberían ocultarse de aplicaciones que no sean de confianza.

Pero posiblemente el escenario extendido realmente justificaría un contenedor chroot + userspace-lxc completo.

información relacionada