3 approcci alla gestione dei segreti per le applicazioni Flatpak

Flatpak consente l'esecuzione delle applicazioni desktop in sandbox isolate, il che migliora notevolmente la sicurezza poiché impedisce alle applicazioni di influenzarsi a vicenda e di influire sul sistema host. In pratica, tuttavia, le applicazioni tipiche devono ancora accedere a servizi e dati utente condivisi tra le altre applicazioni e l'host. Questa situazione è stata migliorata rafforzando le autorizzazioni relative al meccanismo del portale, anche se c'era un problema di vecchia data:come gestire i segreti degli utenti.

In questo articolo, presentiamo il nostro approccio alla gestione dei segreti utente per le applicazioni Flatpak. Sebbene la maggior parte delle applicazioni possa sfruttare in modo trasparente il meccanismo proposto, alcune applicazioni richiedono la modifica del codice. Vengono presentati anche i passaggi della migrazione.

Come vengono gestiti i segreti sul desktop Linux

Su un moderno desktop Linux, la maggior parte dei segreti (password, token e così via, con i relativi attributi associati) sono gestiti centralmente dal processo daemon gnome-keyring-daemon . Le applicazioni accedono a questo demone tramite l'API dei servizi segreti, che è esposta tramite D-Bus. Questo processo viene eseguito di nascosto se l'applicazione utilizza una libreria client come libsecret .

Nota: Per lo stesso scopo, esiste una libreria chiamata libgnome-keyring , ormai obsoleto. Nota che, nonostante il nome, libgnome-keyring è un progetto separato da gnome-keyring , che NON è obsoleto e mantiene ancora il ruolo centrale di gestione dei segreti.

Sul lato demone, i segreti sono archiviati nel filesystem e crittografati. Oltre a questo, il demone non è altro che un normale servizio di archiviazione, il che significa che qualsiasi applicazione può archiviare dati su "percorsi" arbitrari che anche altre applicazioni possono vedere. Sebbene questo modello sia sufficiente purché ci affidiamo a tutte le applicazioni, annulla uno degli obiettivi di sicurezza di Flatpak:aumentare la sicurezza dei sistemi desktop isolando le applicazioni l'una dall'altra.

Pertanto, quando si installa un'applicazione Flatpak che utilizza l'API dei servizi segreti, all'utente viene chiesto di concedere le autorizzazioni necessarie all'applicazione. Nell'esempio seguente, puoi vedere che l'applicazione richiede l'accesso all'API dei servizi segreti (org.freedesktop.secrets ). Se l'utente non desidera consentire a questa applicazione di accedere al servizio, la sua unica opzione è rinunciare all'installazione:

$ 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]:

Questo è chiaramente un risultato indesiderabile.

L'approccio allo storage locale

L'idea di base per affrontare questo problema è archiviare i segreti sul lato dell'applicazione, piuttosto che sul lato host (gnome-keyring-daemon ). Questa pratica è analoga al recente lavoro su GSettings, in cui le applicazioni memorizzano i dati delle impostazioni in un file locale invece che in un dconf servizio in esecuzione sull'host.

Quando si tratta di segreti, tuttavia, c'è un problema di bootstrap:l'applicazione deve crittografare i segreti quando li archivia in un file locale, ma non conosce ancora la chiave di crittografia. Per eseguire il provisioning dell'applicazione con una chiave di crittografia, ci affidiamo al meccanismo del portale Flatpak, che si trova tra l'applicazione e l'host per consentire ai due di comunicare attraverso un'interfaccia limitata.

Abbiamo anche aggiunto un nuovo portale che consente alle applicazioni di recuperare le chiavi di crittografia. Innanzitutto, l'applicazione invia una richiesta al portale (la richiesta contiene un descrittore di file Unix in cui è scritta la chiave di crittografia). Quindi, il portale delega la richiesta all'implementazione di back-end in gnome-keyring-daemon , che invia una chiave di crittografia univoca per l'applicazione sandbox tramite il descrittore di file.

Con la chiave di crittografia ricevuta, l'applicazione crittografa i segreti e li archivia nella directory dei dati dell'applicazione (~/.var/app/$APPID/data/keyrings ), che è vincola -montato e accessibile sia dall'host che dalla sandbox.

L'API libsecret

Il libsecret project fornisce due diversi set di API. Uno è l'API semplice e l'altro è l'API completa. Il primo fornisce operazioni più semplici e stateless per il recupero e la memorizzazione dei segreti, mentre il secondo fornisce un'API orientata agli oggetti più completa che mappa l'interfaccia D-Bus all'API C.

L'archiviazione locale è supportata solo nell'API semplice. Se le tue applicazioni stanno già utilizzando l'API semplice, utilizzeranno automaticamente l'archiviazione locale durante l'esecuzione in Flatpak. In caso contrario, per abilitare l'archiviazione locale, le applicazioni devono essere trasferite sull'API semplice. Vedi la patch di migrazione in Epiphany come esempio.

La distinzione tra i due set di API consente inoltre alle applicazioni di rinunciare all'utilizzo dell'archiviazione locale. Ad esempio, se la tua applicazione è un gestore di password che necessita dell'accesso completo ai keyring utente, puoi ignorare l'archiviazione locale utilizzando l'API completa.

Il formato del portachiavi

Sebbene idealmente dovremmo essere in grado di utilizzare lo stesso formato di portachiavi sia per l'archiviazione locale che per gnome-keyring-daemon , ci siamo resi conto che il formato del portachiavi utilizzato da gnome-keyring-daemon ha dei limiti. I segreti, inclusi gli attributi associati, sono crittografati come un singolo blocco, il che significa che possono consumare una quantità non necessaria di memoria bloccata. Inoltre, gli attributi vengono sottoposti a hash senza una chiave, il che significa che è possibile indovinare quali segreti sono archiviati nel file.

Pertanto, invece di implementare questo formato in due punti, abbiamo deciso di definire una nuova versione del formato del file keyring, con le seguenti caratteristiche: i segreti vengono crittografati individualmente e gli hash degli attributi ora sono un codice di autenticazione del messaggio (MAC) sugli attributi.

Questo nuovo formato è basato sul formato di serializzazione Gvariant, fatta eccezione per l'intestazione, e questa modifica ci consente di riutilizzare la maggior parte del codice per la codifica, la decodifica e la ricerca.

Quali sono le prospettive per la gestione dei segreti Flatpak

Le patch necessarie sono (attualmente) disponibili solo nei repository Git dei componenti rilevanti (xdg-desktop-portal , portachiavi gnomo e libsecret ). Saranno inclusi nelle prossime versioni che portano a GNOME 3.36.

Se sei uno sviluppatore, c'è ancora spazio per miglioramenti in quest'area. Ecco dove il tuo aiuto sarebbe molto apprezzato:

• Portachiavi della sessione: L'API dei servizi segreti supporta i keyring di "sessione", che durano solo per la durata della sessione dell'utente. Il backend di archiviazione locale non supporta ancora questa funzionalità. Questo codice può essere implementato utilizzando il keyring di sessione nel kernel Linux.

• Applicazione di gestione e backup: I segreti dell'applicazione sono ora archiviati in più posizioni e non solo nei keyring dell'host. Sarebbe utile se esistesse uno strumento per gestire i segreti delle applicazioni ed eseguire backup. Questo processo dovrebbe essere possibile migliorando Seahorse di GNOME per esaminare i segreti dell'applicazione.

• Portale degli account online: Al giorno d'oggi, è normale che le applicazioni Web siano integrate con protocolli di delega dell'accesso basati sul Web come OAuth 2.0. Questi protocolli sono supportati da account-gnome-online , che a sua volta utilizza gnome-keyring-daemon per la memorizzazione dei token. Un'interfaccia del portale per gli account online sarebbe utile per limitare l'accesso per applicazione.

• Adozione più ampia del nuovo formato di portachiavi: Sebbene il nuovo formato abbia diversi vantaggi, al momento è utilizzato solo da libsecret sul lato dell'applicazione. Sarebbe utile se gnome-keyring-daemon anche sul lato host utilizzava lo stesso formato.

• Rafforzamento del processo di reinstallazione: Per impostazione predefinita, il file keyring dell'applicazione (~/.var/app/$APPID/data/keyrings ) persiste dopo la disinstallazione, insieme ad altri dati. Questa persistenza è vulnerabile nel caso in cui l'ID applicazione venga riutilizzato da un editore non attendibile. Attualmente, ti consigliamo di utilizzare i --delete-data opzione per garantire che tali dati dell'applicazione vengano rimossi. Questa procedura potrebbe essere migliorata se l'ID di un publisher fosse associato all'applicazione.

Riepilogo

Questo articolo ha presentato un meccanismo per il provisioning delle applicazioni Flatpak con i segreti degli utenti. Questo meccanismo è stato progettato sulla base dei seguenti principi:

• Riduci a icona l'interfaccia host.
• Consenti alle applicazioni di interagire con l'host tramite un portale Flatpak.
• Memorizza i dati dell'applicazione in un formato dati comune.

Sebbene il meccanismo sia trasparente, purché utilizzi libsecret , il meccanismo è abilitato solo tramite libsecret semplice API. Per una transizione più agevole, suggeriamo di migrare le applicazioni a questa API. Maggiori informazioni sullo sfondo del progetto e sulla logica progettuale sono disponibili nella presentazione GUADEC (diapositive, registrazione).