1. Introducción
El siguiente artículo presenta una característica de seguridad en servidores recientemente añadida a #CoreAdmin, y que cierra el acceso a la carpeta especial linux /proc. Tras esta configuración, el acceso queda limitado al usuario administrador, y a todos los usuarios dentro del grupo procaccess.
A continuación te explicamos todos los detalles.
2. ¿Por qué es importante cerrar y limitar el acceso al /proc?
La carpeta especial /proc, incluye muchísima información sensible y que puede ser utilizada por un atacante para explorar, escalar y dirigir un ataque mucho mejor.
El directorio no solo proporciona información de otros procesos, también muestra información de mapeo de memoria, librerías, puntos de montaje, información de la memoria, cpu, tipo, juego de instrucciones, gestión de interrupciones, y un largo listado de elementos informativos valiosísimos para un administrador, pero peligrosos para que estén disponibles para un atacante.
Cerrar el /proc no hace invulnerable el sistema, pero dificulta el proceso de ataque.
3. Cuándo se activa la característica de protección
Core-Admin propondrá automáticamente la activación del cerrado del /proc, cuando detecta una serie de factores que así lo aconseja. Este listado puede ir variando. Actualmente se activa cuando se detectan las siguientes aplicaciones desplegadas:
- Webhosting Management (Gestor de Alojamientos)
- Samba Admin (Administrador Samba)
- Mail Admin (Gestor de correo)
- Docker Manager (Gestor docker)
- Discourse Manager (Gestor Discourse)
- OpenVpn Manager (Gestor OpenVPN)
- Shared Ftp Manager (Gestor de FTP compartido)
También se activa cuando detecta algunos procesos como:
- Procesos Ganeti
- Virtualización kvm/qemu
- Servidores Apache2, Turbulence, PowerDNS
El sistema también realiza varias comprobaciones para evitar activarse para aquellos casos donde no hay posibilidad de reconfiguración automática para hacer que el software afectado pueda seguir funcionando tras la configuración de cierre. El listado incluye:
- Procesos pacemaker (pacemakerd, crmd).
4. Qué componente activa esta característica y cómo configurarlo
Toda la responsabilidad para configurar, desactivar y configurar usuarios autorizados para acceder al /proc la realiza el comprobador users_checker (Checker).
-
Para acceder a su configuración, sigue las siguientes indicaciones. Primero ir a la ficha de la máquina, luego acciones -> mostrar comprobadores y luego:
5. Cómo se realiza el cierre del acceso al /proc
Se usa la configuración estándar de permisos del sistema de ficheros de Linux, junto con un grupo (procaccess) usado para autorizar usuarios, a parte del root, para poder acceder al /proc.
Se puede ver fácilmente la configuración activa ejecutando:
>> ls -la -tr -d /proc
dr-xr-x--- 167 root procaccess 0 abr 14 16:02 /proc
Como se puede observar, la configuración, en esencia, radica en:
- Se elimina el acceso a usuarios others (otros).
- Se configura un grupo (procaccess) para permitir acceso a sus miembros.
- El root sigue siendo propietario, y por tanto, conserva los accesos.
6. Listado de fallos conocidos
A continuación se muestra un listado de fallos conocidos de aplicaciones que necesitan acceso al proc.
Para cada uno de ellos, el problema se resuelve añadiendo el usuario de ejecución al grupo procaccess ya sea por línea de comando, usando el propio configurador del comprobador (en el campo Allowed proc access users, indicado en las secciones anteriores), y también usando la aplicación de Usuarios de sistema de Core-Admin.
-
Fallo conocido de aplicaciones usando npm cuando no tiene acceso al /proc:
>> npm list internal/modules/cjs/loader.js:583 throw err; ^ Error: Cannot find module 'semver' at Function.Module._resolveFilename (internal/modules/cjs/loader.js:581:15) at Function.Module._load (internal/modules/cjs/loader.js:507:25) at Module.require (internal/modules/cjs/loader.js:637:17) at require (internal/modules/cjs/helpers.js:22:18) at Object.<anonymous> (/usr/share/npm/lib/utils/unsupported.js:2:14) at Module._compile (internal/modules/cjs/loader.js:689:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:700:10) at Module.load (internal/modules/cjs/loader.js:599:32) at tryModuleLoad (internal/modules/cjs/loader.js:538:12) at Function.Module._load (internal/modules/cjs/loader.js:530:3) -
Fallo conocido para aplicaciones basadas en java cuando no pueden acceder al /proc:
>> java --version java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory -
Fallo conocido para aplicaciones usando apertium:
Apertium (https://apertium.org/) accede al /proc/meminfo durante su ejecucción. No parece haber manera de desactivarlo. La aplicación deja de funcionar si no tiene acceso al /proc. La única solución es desactivar la característica de protección del cerrado del /proc.
>> echo "<p>Hola, me gustaría pedir una edición</p>" | LANG=es_ES.utf8 strace /usr/local/bin/apertium es-ca -u -f html 2>&1 | grep /proc open(" **/proc/meminfo** ", O_RDONLY|O_CLOEXEC) = -1 **EACCES (Permission denied)** -
Fallo conocido para yarn cuando no tiene acceso al /proc:
Yarn necesita acceso al /proc/meminfo y otros archivos para revisar el estado de la memoria al ejecutar. Si no lo tiene, genera el siguiente error:
>> yarn --help Error: EACCES: permission denied, uv_resident_set_memory at process.memoryUsage (internal/process/per_thread.js:136:5) at ConsoleReporter.checkPeakMemory (/usr/lib/node_modules/yarn/lib/cli.js:33565:40) at ConsoleReporter.initPeakMemoryCounter (/usr/lib/node_modules/yarn/lib/cli.js:33556:10) at /usr/lib/node_modules/yarn/lib/cli.js:92291:14 -
Fallo conocido para sas cuando no tiene acceso al /proc:
La herramienta de preparación de ficheros css SASS requiere acceder al /proc para obtener información del sistema como parte de su proceso. Si no lo tiene, puede generar errores similares al siguiente:
==> ./discourse-3.1.1/log/production.log <== Rendered layout layouts/application.html.erb (Duration: 1138.0ms | Allocations: 268897) Completed 500 Internal Server Error in 2624ms (ActiveRecord: 0.0ms | Allocations: 560880) ActionView::Template::Error (end of file reached) ==> ./discourse-3.1.1/log/puma.err.log <== /var/discourse/comunidad.example.org/.rbenv/versions/3.2.1/lib/ruby/gems/3.2.0/gems/sass-embedded-1.64.1-x86_64-linux-gnu/lib/sass/embedded/connection.rb:28: warning: ../../runtime/vm/os_thread.cc: 59: error: Failed to retrieve stack bounds
7. Cómo resolver / añadir usuarios al grupo procaccess
Dispones de los siguientes métodos para añadir/gestionar usuarios al procaccess, y que por tanto, tendrán acceso (sólo de lectura):
-
Añadir el usuario en el listado de “Allowed proc access user”, dentro de la configuración del checker users_checkers (tal y como se muestra en las secciones anteriores):
NOTA: Una vez añadido el usuario, hay que “Ejecutar” el checker para que se aplique la configuración.
NOTA 2: Tenga en cuenta que este método no muestra todos los usuarios actualmente metidos el grupo procaccess. Sólo muestra los que han sido configurados en el checker para ser añadidos.
Si necesita gestionar (quitar) y visualizar qué usuarios están actualmente metidos en grupo procaccess, vea los siguientes dos métodos.
-
Añadir/gestionar usuarios en el grupo procaccess usando la herramienta de administración de usuarios del sistema. La tendrá que desplegar si no la tiene disponible: Maquina -> Acciones -> Mostrar configuración de la máquina -> Aplicaciones -> Buscar Gestión de usuarios del sistema, desplegar, marcar como instalada y darle a editar.
Una vez disponible, arrancar:
Y luego diríjase al grupo procaccess para ver los miembos actuales (ordenando la columna de selección):
-
El último método, es simplemente añadir el usuario directamente desde línea de comandos:
# para sistemas debian/ubuntu >> adduser <usuario> procaccess # para sistemas centos >> usermod -a -G procaccess <usuario>
8. Tipo de acceso concedido sí estás en el grupo procaccess
En cualquier caso, sea cual sea el método usado, en cuanto un usuario esté dentro del grupo procaccess, tendrá el mismo acceso que en un sistema sin cierre de proc: acceso de lectura a los ficheros, limitado por el resto de componentes que pudieran haber (como hidepid del mount).