Dentro del contexto de verificación de permisos en sistemas UNIX, la mayoría de implementaciones (Linux, MacOS, BSD) presenta dos categorías básicas de procesos:
- Procesos privilegiados que necesitan ser ejecutados por un usuario con user id 0 o sea root
- Procesos no privilegiados que pueden ser ejecutados por cualquier usuario sin importar su user id
Los procesos privilegiados por defecto omiten todas las verificaciones de seguridad propias del kernel, y aunque el camino mas rápido para ejecutar este tipo de procesos es ejecutarlos como root, existen entornos de mínimos privilegios donde esto no es deseable. Motivado por esto y desde el kernel 2.2, Linux divide los permisos de root en 32 unidades denominadas Linux capabilites, con lo cual es posible conceder ciertos privilegios a los procesos sin que esto signifique dar el acceso total como root.
Permisos para la JVM
Para utilizar Linux capabilities es necesario asignar los permisos sobre el ejecutable que deseamos administrar, vale la pena resaltar que Linux capabilities no esta diseñado para funcionar sobre links simbolicos y hay que encontrar la ruta real donde esta ubicado nuestro ejecutable:
$ whereis java java: /usr/bin/java /opt/icedtea-bin-7.2.3.4/bin/java
Una vez hemos determinado donde se encuentra el ejecutable asignamos uno de los 32 permisos sobre el ejecutable, por ejemplo para habilitar el acceso raw a sockets (CAP_NET_RAW)
# setcap cap_net_raw+epi /opt/icedtea-bin-7.2.3.4/bin/java
Luego de asignar los permisos es probable que al ejecutar Java obtengamos el siguiente error:
/opt/icedtea-bin-7.2.3.4/bin/java: error while loading shared libraries: libjli.so: cannot open shared object file: No such file or directory
De acuerdo a un bug publicado en el bugtracker de java esto se debe a que algunas bibliotecas como libjli.so no estan dentro del path «bendecido» por el kernel (/usr/lib) y por lo tanto a pesar de que el ejecutable tiene garantizados los permisos, la biblioteca no.
Solución
Para que estas bibliotecas formen parte de las bibliotecas «bendecidas» la solución es agregar un archivo de configuración dentro de /etc/ld.so.conf.d/ con el mismo nombre del ejecutable, en este caso java.conf, el contenido de este archivo deben ser los directorios autorizados
cat "/opt/icedtea-bin-7.2.3.4/jre/lib/amd64/jli/" >> /etc/ld.so.conf.d/java.conf |
Vale la pena resaltar que a diferencia de capabilities, ldconfig si trabaja sobre enlaces simbólicos, y en sistemas como Gentoo donde se puede tener más de una maquina virtual la sintaxis alternativa seria:
cat "/etc/java-config-2/current-system-vm/jre/lib/amd64/jli" >> /etc/ld.so.conf.d/java.conf |
Hecho esto podemos comprobar que todo este funcionando de manera correcta, la salida debería ser similar a la siguiente:
# ldconfig | grep libjli libjli.so -> libjli.so # java -version java version "1.7.0_09" OpenJDK Runtime Environment (IcedTea7 2.3.4) (Gentoo build 1.7.0_09-b30) OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)