Configurar el sandbox de plugins¶
Qué configuración de sandbox conviene a tu servidor, en palabras sencillas. Para casi todo el mundo la respuesta es: deja los valores por defecto. El servidor detecta la máquina y elige el aislamiento más fuerte que puede. Sigue leyendo solo si tienes un NAS antiguo, si usas Evey sin Docker o si quieres un aislamiento más fuerte. El modelo técnico completo está en Sandbox de plugins y modelo de amenazas.
Qué te protege¶
Un plugin que instalas se ejecuta aislado. Según la máquina, ese aislamiento:
- limita los archivos que puede tocar: su propia carpeta y las bibliotecas del sistema que necesita, nada más (ni tus medios, ni tus secretos, ni los demás plugins);
- bloquea las acciones peligrosas del sistema en el kernel: depurar otros procesos, cargar módulos, cambiar la hora, montar discos;
- corta el acceso directo a la red, siempre: un plugin que pidió la red, y al que tú se la diste, solo llega a los servidores que declaró, y siempre pasando por el servidor de Evey;
- limita la CPU, la memoria, el disco y el número de procesos, para que un plugin que consume demasiado no pueda dejar fuera de servicio el servidor;
- mantiene tus secretos ilegibles: la clave que firma los inicios de sesión y las copias de seguridad.
Además, solo un administrador puede instalar plugins, se analizan en busca de código sospechoso y tú apruebas sus permisos antes de que se ejecuten.
Comprueba lo que está activo: Administración → Plugins → Panel de
seguridad muestra el sandbox del equipo, el modo que eligió auto
(landlock, bubblewrap o basic) y los resultados de las pruebas
(Kernel Landlock, Lanzador del sandbox, Bubblewrap). basic significa
que el equipo no ofrece aislamiento de archivos por carpeta: los plugins se
ejecutan solo con un cambio de usuario (uid) y seccomp, las pruebas dicen por
qué, y las secciones siguientes explican qué cambiar.
Elige tu situación¶
| Tu servidor | Lo que tienes sin hacer nada | ¿Algo que hacer? |
|---|---|---|
| Linux moderno con Docker (kernel 5.13 o posterior, es decir, casi todo lo que salió desde 2021), el caso normal | el aislamiento más fuerte (Landlock), automáticamente | nada |
| NAS antiguo con Docker (kernel anterior a 5.13) | buen aislamiento, sin la restricción de archivos por carpeta; los secretos, la red y las acciones del sistema siguen bloqueados | nada: la separación de uid (más abajo) se activa sola |
| Cualquier Linux, sin Docker | el aislamiento más fuerte disponible: Landlock en un kernel moderno, si no, los espacios de nombres de bubblewrap | sigue Sin contenedor |
El único ajuste que quizá cambies: la separación de uid¶
La separación de uid hace que un plugin se ejecute con una cuenta de usuario
distinta de la del servidor, así que no puede leer los archivos
secretos del servidor aunque nada más se lo impidiera. Solo importa en una
máquina sin la restricción de archivos por carpeta (el caso basic); en una
máquina moderna, esa restricción ya mantiene los secretos fuera de su alcance, y
la separación es una capa extra redundante.
EVEY_PLUGINS_UID_SEPARATION:
| Valor | Significado | Úsalo cuando |
|---|---|---|
auto (por defecto) |
activa solo cuando hace falta (el caso basic), desactivada donde es redundante |
siempre, salvo que se dé uno de los dos casos siguientes |
on |
siempre activa, una segunda protección independiente además de la restricción de archivos | quieres las dos protecciones y aceptas el pequeño coste descrito más abajo |
off |
nunca | un plugin concreto funciona mal con ella (poco frecuente) |
Warning
La separación de uid es incompatible con la opción de Docker
no-new-privileges: elige una de las dos. Cuando no se puede cambiar de
usuario en una máquina antigua (basic), el servidor se niega a arrancar
el plugin en lugar de ejecutarlo junto a tus secretos; en una máquina
moderna, registra un aviso y ejecuta el plugin sin la protección adicional. La
imagen trae todo lo necesario, solo tienes que definir la variable.
El pequeño coste de on: el plugin se ejecuta con una cuenta aparte, así que
un plugin que escribe archivos temporales en su propia carpeta puede fallar.
Si pasa, pon off. Por eso el valor por defecto es auto: solo asume ese
riesgo donde hay un beneficio real.
Lo que podría hacer un plugin malicioso¶
Linux moderno (con Docker o sin él): un plugin malicioso queda completamente aislado. No puede leer tus secretos, no puede ver ni tocar los archivos de otros plugins, no puede hacer llamadas de red arbitrarias y no puede alterar el sistema. La única salida realista sería un fallo grave del kernel, algo que vale para cualquier sandbox que no sea una máquina virtual completa.
NAS antiguo con Docker, sin restricción de archivos por carpeta (basic):
- tus secretos siguen protegidos (clave de inicio de sesión, copias de
seguridad) gracias a la cuenta de usuario aparte, que
autoactiva aquí; - el plugin no tiene acceso directo a la red; uno que tenga permiso solo llega a los servidores que declaró;
- las acciones peligrosas del sistema siguen bloqueadas en el kernel;
- pero sin restricción de archivos por carpeta, un plugin malicioso podría leer archivos corrientes que no son secretos, ver la lista de procesos en marcha y, como los plugins comparten una misma cuenta, leer o alterar los archivos de otro plugin.
En un equipo así, instala solo plugins de confianza, o pasa a un kernel moderno para tener la restricción de archivos completa.
Ejemplos de configuración¶
Cada línea va bajo environment: en el archivo compose, escrita
KEY: value (por ejemplo EVEY_PLUGINS_UID_SEPARATION: "on").
EVEY_PLUGINS_SANDBOX_MODE=auto # elige el más fuerte disponible (por defecto)
# EVEY_PLUGINS_UID_SEPARATION=auto # (por defecto) activa solo donde hace falta
# no pongas no-new-privileges en el security_opt del compose, bloquearía el cambio de usuario
EVEY_PLUGINS_SANDBOX_MODE=auto
EVEY_PLUGINS_UID_SEPARATION=auto # (por defecto) activa en el caso basic
EVEY_PLUGINS_SANDBOX_MODE=auto # queda en landlock
EVEY_PLUGINS_UID_SEPARATION=on # añade además la separación de uid independiente
EVEY_PLUGINS_SANDBOX_MODE=landlock # no arranca los plugins si Landlock no está disponible
EVEY_PLUGINS_MEMORY_MB=256 # RAM máxima por plugin
EVEY_PLUGINS_PIDS_MAX=64 # número máximo de procesos e hilos
EVEY_PLUGINS_DISK_MAX_MB=100 # tamaño máximo de la carpeta de instalación (0 = sin límite)
EVEY_PLUGINS_CPU_NICE=10 # prioridad de CPU 0-19 (más alto = más cede a los demás)
Cambiar el modo de sandbox en marcha¶
Cambia el Modo de sandbox en la tarjeta Límites de recursos de
Administración → Plugins. Los plugins en marcha se reinician
automáticamente para que el nuevo modo se aplique enseguida, y el Panel de
seguridad muestra el modo activo. Un plugin que no puede funcionar con el
nuevo modo (por ejemplo bubblewrap dentro de un contenedor sin privilegios)
aparece con error: vuelve al modo anterior.
Verificar que funciona¶
# el lanzador lleva la capacidad que usa la separación de uid
docker exec evey-server getcap /evey-plugin-launcher # cap_setuid=ep
# con qué usuario se ejecuta un plugin en marcha (evey = compartido con el servidor,
# evey-plugin = separado); la imagen tiene ps, así que `docker exec evey-server ps` también funciona
docker top evey-server -o user,pid,args | grep -iE "node|python"
El modo de sandbox activo es la insignia de Administración → Plugins → Panel de seguridad.