3 enfoques para la gestión de secretos para aplicaciones Flatpak

Flatpak permite que las aplicaciones de escritorio se ejecuten en entornos aislados, lo que mejora significativamente la seguridad, ya que evita que las aplicaciones se afecten entre sí y afecten al sistema host. En la práctica, sin embargo, las aplicaciones típicas aún necesitan acceder a servicios y datos de usuario que se comparten entre otras aplicaciones y el host. Esta situación se ha mejorado fortaleciendo los permisos en torno al mecanismo del portal, aunque había un problema de larga data:cómo administrar los secretos de los usuarios.

En este artículo, presentamos nuestro enfoque para administrar los secretos de usuario para las aplicaciones Flatpak. Si bien la mayoría de las aplicaciones pueden aprovechar de forma transparente el mecanismo propuesto, algunas aplicaciones necesitan modificar el código. También se presentan los pasos de migración.

Cómo se administran los secretos en el escritorio de Linux

En un escritorio Linux moderno, la mayoría de los secretos (contraseñas, tokens, etc., con sus atributos asociados) son administrados de forma centralizada por el proceso daemon gnome-keyring-daemon . Las aplicaciones acceden a este demonio a través de la API del Servicio Secreto, que se expone a través de D-Bus. Este proceso se realiza bajo el capó si la aplicación usa una biblioteca de cliente como libsecret .

Nota: Para el mismo propósito, existe una biblioteca llamada libgnome-keyring , que ahora está obsoleto. Tenga en cuenta que, a pesar del nombre, libgnome-keyring es un proyecto separado de gnome-keyring , que NO está obsoleto y aún mantiene el papel central de la gestión de secretos.

En el lado del demonio, los secretos se almacenan en el sistema de archivos y se cifran. Aparte de eso, el daemon no es más que un servicio de almacenamiento normal, lo que significa que cualquier aplicación puede almacenar datos en "rutas" arbitrarias que otras aplicaciones también pueden ver. Si bien este modelo es suficiente siempre que confiemos en todas las aplicaciones, anula uno de los objetivos de seguridad de Flatpak:aumentar la seguridad de los sistemas de escritorio aislando las aplicaciones entre sí.

Por lo tanto, al instalar una aplicación Flatpak que utiliza la API del Servicio Secreto, se le solicita al usuario que otorgue los permisos necesarios a la aplicación. En el siguiente ejemplo, puede ver que la aplicación requiere acceso a la API del Servicio Secreto (org.freedesktop.secrets ). Si el usuario no desea permitir que esta aplicación acceda al servicio, su única opción es renunciar a la instalación:

$ flatpak install org.gnome.Epiphany

…

org.gnome.Epiphany permissions:

        ipc                     network         pulseaudio      wayland

        x11                     dri             file access [1] dbus access [2]

        system dbus access [3]



        [1] xdg-download, xdg-run/dconf, ~/.config/dconf:ro

        [2] ca.desrt.dconf, org.freedesktop.Notifications, org.freedesktop.secrets

        [3] org.freedesktop.GeoClue2

Proceed with these changes to the Default system installation? [Y/n]:

Esto es claramente un resultado indeseable.

El enfoque de almacenamiento local

La idea básica para abordar este problema es almacenar los secretos en el lado de la aplicación, en lugar del lado del host (gnome-keyring-daemon ). Esta práctica es análoga al trabajo reciente en GSettings, donde las aplicaciones almacenan los datos de configuración en un archivo local en lugar de en un dconf. servicio ejecutándose en el host.

Sin embargo, cuando se trata de secretos, existe un problema de arranque:la aplicación tiene que cifrar los secretos cuando los almacena en un archivo local, pero aún no conoce la clave de cifrado. Para aprovisionar la aplicación con una clave de cifrado, confiamos en el mecanismo del portal Flatpak, que se ubica entre la aplicación y el host para permitir que ambos se comuniquen a través de una interfaz restringida.

También agregamos un nuevo portal que permite que las aplicaciones recuperen claves de cifrado. Primero, la aplicación envía una solicitud al portal (la solicitud contiene un descriptor de archivo Unix donde se escribe la clave de cifrado). Luego, el portal delega la solicitud a la implementación de back-end en gnome-keyring-daemon , que envía una clave de cifrado única para la aplicación de espacio aislado a través del descriptor de archivo.

Con la clave de cifrado recibida, la aplicación cifra los secretos y los almacena en el directorio de datos de la aplicación (~/.var/app/$APPID/data/keyrings ), que es vincular -montado y accesible tanto desde el host como desde el sandbox.

La API de libsecret

El libsecret project proporciona dos conjuntos diferentes de API. Una es la API simple y la otra es la API completa. El primero proporciona operaciones más simples y sin estado para recuperar y almacenar secretos, mientras que el segundo proporciona una API más completa y orientada a objetos que asigna la interfaz D-Bus a la API C.

El almacenamiento local solo se admite en la API simple. Si sus aplicaciones ya utilizan la API simple, utilizarán automáticamente el almacenamiento local cuando se ejecuten en Flatpak. De lo contrario, para habilitar el almacenamiento local, las aplicaciones deben migrarse a la API simple. Vea el parche de migración en Epiphany como ejemplo.

Tener una distinción entre los dos conjuntos de API también hace posible que las aplicaciones dejen de usar el almacenamiento local. Por ejemplo, si su aplicación es un administrador de contraseñas que necesita acceso total a los conjuntos de claves de los usuarios, puede omitir el almacenamiento local utilizando la API completa.

El formato de llavero

Aunque idealmente, deberíamos poder usar el mismo formato de llavero tanto para el almacenamiento local como para gnome-keyring-daemon , nos dimos cuenta de que el formato de llavero usado por gnome-keyring-daemon tiene limitaciones Los secretos, incluidos los atributos asociados, se cifran como un solo fragmento, lo que significa que pueden consumir una cantidad innecesaria de memoria bloqueada. Además, los atributos se codifican sin una clave, lo que significa que es posible adivinar qué secretos están almacenados en el archivo.

Por lo tanto, en lugar de implementar este formato en dos lugares, decidimos definir una nueva versión del formato de archivo de llavero, con las siguientes características: Los secretos se cifran individualmente y los hashes de atributos ahora son un código de autenticación de mensajes (MAC) sobre los atributos.

Este nuevo formato se basa en el formato de serialización GVariant, excepto por el encabezado, y este cambio nos permite reutilizar la mayor parte del código para codificar, decodificar y buscar.

Qué sigue para la gestión de secretos de Flatpak

Los parches necesarios (actualmente) solo están disponibles en los repositorios Git de los componentes relevantes (xdg-desktop-portal , llavero-gnomo y libsecret ). Se incluirán en los próximos lanzamientos previos a GNOME 3.36.

Si es un desarrollador, todavía hay margen de mejora en esta área. Aquí es donde su ayuda sería muy apreciada:

• Llaveros de sesión: La API del Servicio Secreto admite llaveros de "sesión", que solo duran la duración de la sesión del usuario. El backend de almacenamiento local aún no es compatible con esta función. Este código podría implementarse utilizando el conjunto de claves de sesión en el kernel de Linux.

• Aplicación de gestión y copia de seguridad: Los secretos de las aplicaciones ahora se almacenan en varias ubicaciones, y no solo en los conjuntos de claves del host. Sería útil que existiera una herramienta para gestionar los secretos de las aplicaciones y realizar copias de seguridad. Este proceso debería ser posible al mejorar Seahorse de GNOME para ver los secretos de las aplicaciones.

• Portal de cuentas en línea: Actualmente, es común que las aplicaciones web se integren con protocolos de delegación de acceso basados ​​en la web, como OAuth 2.0. Estos protocolos son compatibles con gnome-online-accounts , que a su vez usa gnome-keyring-daemon para almacenar las fichas. Una interfaz de portal para cuentas en línea sería útil para restringir el acceso por aplicación.

• Adopción más amplia del nuevo formato de llavero: Si bien el nuevo formato tiene varias ventajas, actualmente solo lo usa libsecret en el lado de la aplicación. Sería beneficioso si gnome-keyring-daemon en el lado del anfitrión también usó el mismo formato.

• Reforzando el proceso de reinstalación: De forma predeterminada, el archivo de llavero de la aplicación (~/.var/app/$APPID/data/keyrings ) persiste después de la desinstalación, junto con otros datos. Esta persistencia es vulnerable en caso de que un editor que no sea de confianza reutilice el ID de la aplicación. Actualmente, recomendamos usar --delete-data opción para asegurarse de que dichos datos de la aplicación se eliminen. Este procedimiento podría mejorarse si la identificación de un editor estuviera asociada con la aplicación.

Resumen

Este artículo presentó un mecanismo para aprovisionar aplicaciones Flatpak con secretos de usuario. Este mecanismo fue diseñado en base a los siguientes principios:

• Minimice la interfaz del host.
• Permita que las aplicaciones interactúen con el host a través de un portal Flatpak.
• Almacene los datos de la aplicación en un formato de datos común.

Aunque el mecanismo es transparente, siempre y cuando uses libsecret , el mecanismo solo se habilita a través de libsecret La API simple de . Para una transición más fluida, sugerimos migrar aplicaciones a esta API. Más información sobre los antecedentes del proyecto y la justificación del diseño está disponible en la presentación de GUADEC (diapositivas, grabación).