FLATPACK Sistema de Instalación y Gestión de Paquetes en Linux que no está en FreeBSD

Flatpak es una herramienta de instalación de software y gestión de paquetes para Linux.

Este proporciona un ambiente aislado de funcionamiento tipo caja de arena (sand box) en el cual los usuarios pueden ejecutar aplicaciones de software en aislamiento (parcial) del resto del sistema. Anteriormente a flatpak se le conocía como xdg-app hasta 2016 y formaba parte del sistema FreeDesktop.

La última versión de Flatpak al 14 de Agosto de 2024 es la 1.14.10.

Su funcionamiento general permite a desarrolladores el crear paquetes de software para que puedan ser instalados en cualquier distribución de Linux (Ubuntu, Mint, Debian, Arch, por mencionar solo algunos) sin que el desarrollador tenga que hacer modificaciones específicas para cada distribución y de esa forma no tener que lidiar con un ambiente disperso y fraccionado, la idea en principio es que se instale una base de flatpak que en un principio provocará que los paquetes de software de flatpak que se instalen ocupen un espacio mayor que las aplicaciones instaladas de forma nativa, sin embargo conforme se vayan instalando más paquetes basados en flatpak el espacio en disco se irá haciendo cada vez más óptimo, los paquetes que se instalan normalmente se obtienen del sitio "flathub.org".

Hasta este punto todo pinta muy bien, sin embargo el sistema flatpak esta intrínsecamente integrado a Linux y llamadas de sistema y al esquema name-spaces de Linux que actualmente no existe en otros sistemas como los bsd (NetBSD, FreeBSD, OpenBSD, etc....)

La razón es precisamente que flatpak es útil debido al fragmentado entorno de las distribuciones de Linux y en ese caso es muy útil, algo que no ocurre con los BSD que tienen un ambiente más homogéneo y las herramientas actuales como los ports o el sistema pkg ya realizan esas funciones bastante bien, pero hay otras razones menos conocidas por las cuales el sistema flatpak no sería viable en la familia de sistemas bsd como veremos a continuación:

Como antecedente esta información que se va a presentar fue mencionada en diferentes sitios de Internet por usuarios de Linux, de tal forma que no exista un sesgo por parte de un servidor que de por si se inclina a FreeBSD, de esta forma
se procura ser más imparcial.

El siguiente texto es una traducción del sitio <flatkill.org/2020/>

Flatpak - una pesadilla de seguridad - 2 años después (2020)

Hace 2 años se escribió un post sobre en aquel entonces el muy publicitado Flatpak, auto proclamado como "El futuro de las Apps en Linux". El post criticó las siguientes 3 mayores fallas en Flatpak:

• La Mayoría de las apps tienen acceso completo al sistema del anfitrión pero los usuarios son engañados para creer que las apps
  están en un entorno de aislamiento tipo caja de arena (sand-box).
• Los entornos en tiempo de ejecución de flatpak y las apps no reciben actualizaciones de seguridad.
• Flatpak rompe muchos aspectos de la integración de escritorio.

Ahora veamos como han resuelto los desarrolladores de Flatpak estos problemas fundamentales.

La caja de arena (sandbox) sigue siendo AÚN una mentira

Prácticamente todas las apps populares en Flathub.org aún vienen con permisos del tipo "filesystem=host" o "filesystem=home", en otras palabras, vienen con el acceso de escritura al directorio "home" (y más) de tal forma que todo lo que se necesita para escapar de la caja de arena es un trivial:

echo "descargar_y_ejecutar_el_mal" >> ~/.bashrc

Y es todo!

Las aplicaciones más populares en Flathub aún sufren de esto - Gimp, VSCodium, PyCharm, Octave, Inkscape, Audacity, VLC aún no están en un entorno de caja de arena.

Y, finalmente, los usuarios aún siguen engañados por el tranquilizador icono azul "sandboxed". Dos años no son suficientes para agregar una advertencia de que una aplicación no está en un entorno de caja de arena si viene con permisos peligrosos (como el acceso completo a su directorio "home")? Es en serio?

Imagen tomada del siguiente sitio: https://flatkill.org/2020/sandboxlie.png.

Las apps y librerías en tiempo de ejecución de Flatpak AÚN contienen huecos de seguridad conocidos desde hace tiempo

Me tomó unos 20 minutos encontrar la primera vulnerabilidad en una aplicación de Flathub con acceso completo al anfitrión y ni siquiera me molesté en usar un scanner de vulnerabilidades.

Un ejemplo perfecto es el aviso CVE-2019-17498 con un exploit público disponible desde hace 8 meses. La primera app en Flathub que encontré para usar la biblioteca libssh2 es Gitg y, al final, viene con una biblioteca libssh2 sin parchar.

Pero, ¿Solo es esta aplicación?, veamos las bibliotecas de tiempo de ejecución oficiales en el corazón de Flatpak (org.freedesktop.Platform y org.gnome.Platform 3.36 - que al momento de escribir este post eran usadas por la mayoría de las aplicaciones en Flathub). La primera vulnerabilidad sin parchar que encontré en las bibliotecas oficiales en tiempo de ejecución fue ffmpeg en la versión 4.2.1 sin parches de seguridad aplicados, según el aviso CVE-2020-12284.

Recientemente me tropecé con un articulo de 2011 donde se menciona el inicio de lo que hoy conocemos como flatpak, en palabras del fundador del proyecto:

"Otros problema es con las actualizaciones de seguridad (o correcciones de bugs) en bibliotecas embebidas. Con las bibliotecas embebidas es mucho más difícil de actualizar una sola biblioteca, ya que necesitas encontrar y actualizar cada app que la use. Mejores herramientas y soporte de actualización podrían reducir el impacto de esto. pero no elimanrlo completamente."

Después de leer eso, se hizo claro que no debería sorprendernos que flatpak aún sufra de estos mismos problemas de seguridad que los de hace dos años, debido a que los desarrolladores de flatpak conocen sobre estos problemas desde el principio.

Los exploits locales de "root" ya NO son considerados un problema menor!

Grandioso! Hace dos años escribí sobre lo trivial que es introducir un exploit de root local usando flatpak para instalar binarios suid como se menciona en el (CVE-2017-9780) y como ésto ha sido minimizado como un problema menor de seguridad. Me alegra ver qie al fin la actitud hacia los exploits de root locales ha cambiado el día de hoy, ya que ahora son considerados de alta severidad.

Integración de Escritorio

La fuentes de Sistema y de usuario ahora están disponibles en aplicaciones flatpack y las configuraciones básicas del rendereo son respetados también, sin embargo no esperen que sus cambios en /etc/fonts, puedan típicamente asignar una letra adecuada de respaldo para caracteres CJK (Chino, Japones, Coreano), y que funcione con flatpak. Las aplicaciones KDE en flatpak aún siguen ignorando la configuración de los temas, letras e iconos (probado con Qt5ct). Las aplicaciones instaladas desde las fuentes de la distribución no tienen este problema por supuesto. Una captura de pantalla rápida lo puede demostrar.

Imagen tomada desde https://flatkill.org/2020/desktopbrokenation.mp4.

Aún más importante, "fcitx", el IME para Chino aún está roto - ya han pasado 2 años. Aquí esta el problema que mencioné hace 2 años - Es de interés especial el siguiente comentario directamente del desarrollador de "fcitx":

"Debido a que el módulo im de fcitx en flatpak es de la versión 4.2.97 y está usando una ruta de objeto dbus diferente. Este necesita ser de la misma versión en tu anfitrión."

Así que necesito ejecutar múltiples daemons fcitx en mi escritorio y cambiar entre ellos conforme cambio de apps de flatpacj dependiendo de cuales bibliotecas esté embebidas en ellas o quizas en el futuro de las apps de Linux no sea posible teclear caracteres en chino y eso este bien?

Mientras que la estrategia de "todo embebido" a probado ser útil en servidores claramente no funciona para aplicaciones de escritorio, continuemos enlazando bibliotecas de sistema en aplicaciones de escritorio (y usemos las bibliotecas embebidas como un reemplazo en caso de fallo solamente) para evitar introducir estos problemas en el escritorio de Linux.