Project

General

Profile

Feature #16718

Consider adding back a Persistence feature for GNOME keyring

Added by jonathonz 3 months ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Persistence
Target version:
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

I understand that a decision was taken to eliminate GNOME keyring from persistence. https://redmine.tails.boum.org/code/issues/15275

Is it possible to revisit this decision?

One of the use cases mentioned in the previous link was the ability to store passwords for USB encrypted volumes. This is very helpful functionality for those who regularly use these volumes such as in the case of SecureDrop. www.securedrop.org

I just installed Tails 3.6, setup persistence of GNOME keyring, setup an encrypted USB, saved password and upgraded to 3.13.2 in order to keep the functionality but stay current. Not sure how long this will be sustainable for.

remember-password.png View (23.6 KB) sajolida, 05/15/2019 03:44 PM


Related issues

Related to Tails - Bug #15275: Remove the GNOME Keyring persistent feature Resolved 02/01/2018

History

#1 Updated by eloquence 3 months ago

FYI, SecureDrop directly relied on this persistence feature as part of our setup instructions, to minimize the passphrase juggling required:

https://docs.securedrop.org/en/release-0.12.2/set_up_transfer_device.html

For now we'll update our docs to work around this (tracker here: https://github.com/freedomofpress/securedrop/issues/4434), but it was definitely a nice convenience feature for SecureDrop admins.

#2 Updated by jonathonz 3 months ago

Not just for SecureDrop admins. Everytime a journalist moves the transfer USB key, which is encouraged to have a long diceware password, this passphrase would need to be retyped twice (on the journalist and secureview stations) if the feature didn't exist.

eloquence wrote:

FYI, SecureDrop directly relied on this persistence feature as part of our setup instructions, to minimize the passphrase juggling required:

https://docs.securedrop.org/en/release-0.12.2/set_up_transfer_device.html

For now we'll update our docs to work around this (tracker here: https://github.com/freedomofpress/securedrop/issues/4434), but it was definitely a nice convenience feature for SecureDrop admins.

#3 Updated by intrigeri 3 months ago

  • Related to Bug #15275: Remove the GNOME Keyring persistent feature added

#4 Updated by intrigeri 3 months ago

  • Category set to Persistence
  • Type of work changed from Code to Discuss

@sajolida, reading the arguments provided here makes me lean towards reverting the decision we made on #15275. What do you think?

#5 Updated by mercedes508 3 months ago

  • Status changed from New to Confirmed

#6 Updated by sajolida 3 months ago

First of all, I don't remember seeing you @jonathonz and @eloquence on our bug tracker in the past. So welcome! You should come by more often :)

Reading again #15275, I think that we overlooked this use case. I have myself some passwords of encrypted USB sticks saved in persistence but I'm realizing only now that they only work because I still have the old line in my persistence.conf.

As a workaround and if you're comfortable with editing file from the command line, you can add yourself the following line to /live/persistence/TailsData_unlocked/persistence.conf:

/home/amnesia/.gnome2/keyrings  source=gnome-keyrings

I'm fine with adding back the GNOME Keyring persistence feature but before I'll want to rephrase it to make it clear the most obvious use cases. Whatelse is it useful for in vanilla Tails?

Because if that's its only use case, I'm almost tempted to add it by default to persistence.conf. People are already asked to "Remember password" in the unlocking dialog of GNOME, so making this remembering work by default could be what people expect, even in Tails. This would work only if there no other significant use cases for GNOME Keyring in Tails that might conflict with people's expectation if they were enabled by default.

#7 Updated by intrigeri 3 months ago

  • Assignee changed from intrigeri to sajolida

What else is it useful for in vanilla Tails?

In vanilla Tails:

  • Seahorse can store SSH passphrases in the GNOME Keyring. I don't know if this feature is currently available in Tails (if not, an upgrade to a new version of Debian, or a missing dependency installed for unrelated reasons, could make it suddenly available).
  • It's hard to tell what else uses it and what for, because:
    • Lots of software we ship depends (directly or transitively) on libsecret-1-0, which allows using GNOME Keyring: for example Brasero, Evince, and Nautilus. I don't know what kind of secrets they may — silently or not — store in there currently, let alone in the future.
    • Other programs may use GNOME Keyring iff. it's available, without this being expressed by package dependencies.

And of course, Additional Software can use GNOME Keyring (today or at some point in the future). For example, deja-dup uses it via libsecret-1-0.

People are already asked to "Remember password" in the unlocking dialog of GNOME, so making this remembering work by default could be what people expect, even in Tails.

At first glance, I strongly disagree: we ship dozens of programs that offer the user to "Save" stuff and unless the user explicitly chooses a destination file that's on the persistent volume, "saved" stuff will be forgotten next time you reboot. So I would assume that the expectation this surrounding environment creates is that "remember", as a synonym of "save", implicitly means "until I reboot". But perhaps I'm missing something behind your reasoning? I'm curious! :))) Anyway, this is probably moot because:

This would work only if there no other significant use cases for GNOME Keyring in Tails that might conflict with people's expectation if they were enabled by default.

libsecret is the standard way for desktop apps to store secrets. Many programs use it and more may start using it at any point in the future. So I don't think that a list of "significant use cases" there is for it in vanilla Tails currently is a good enough criterion wrt. making the data of libsecret's GNOME storage backend persistent by default.

So I'm afraid that:

  • It feels like a very bad idea to make this persistent by default.
  • The way we present what data is covered by this persistence setting to users will have to be pretty broad and non-specific: we can't pretend one opts-in to make "only $this and $that" persistent when enabling it. We have no way to guarantee how large its scope can become, even ignoring Additional Software (which I don't think we should but that does not matter at this point).

I know these conclusions totally suck from a UX point of view but I see no way around it, apart of implementing our own libsecret backend, that would only allow some specific apps to store secrets. Even if it was possible (I think it's not yet), chances are this would be rather costly.

#8 Updated by sajolida 3 months ago

At first glance, I strongly disagree: we ship dozens of programs that offer the user to "Save" stuff and unless the user explicitly chooses a destination file that's on the persistent volume, "saved" stuff will be forgotten next time you reboot. So I would assume that the expectation this surrounding environment creates is that "remember", as a synonym of "save", implicitly means "until I reboot". But perhaps I'm missing something behind your reasoning? I'm curious! :))) Anyway, this is probably moot because:

I understand. I think that this reveals another deeper problem which
relates to a core mental model issue around Persistence.

We say "leave no trace on the computer you are using unless you ask it
explicitly" when it actually means "leave no trace on the computer you
are using unless you ask it explicitly to Tails".

And implies that people are able to make a clear distinction between:

  • What is Tails (eg. Persistence settings, default KeePassX database
    location, Additional Software notifications, and maybe other things).
  • What is not Tails ("Remember password" in GNOME Shell and maybe other
    places as you said).

The distinction is pretty easy for us to understand as veteran Linux and
GNOME users: we understand that Tails is an additional layer on top of
GNOME. But I bet that someone who knows little about computers and never
used anything else than Windows wouldn't make this difference. So far
I've done very little usability tests with such people so I don't have
good data on this.

But yes, I agree with you and we shouldn't do what I proposed :)

libsecret is the standard way for desktop apps to store secrets. Many programs use it and more may start using it at any point in the future. So I don't think that a list of "significant use cases" there is for it in vanilla Tails currently is a good enough criterion wrt. making the data of libsecret's GNOME storage backend persistent by default.

Ok, so basically we have a storage for secrets without knowing really
what it will store and this might evolve without us noticing.

I'm afraid that such a vague Persistence feature will be unhelpful for
users. They won't be able to know, without evolved and time consuming
trial and error:

  • What useful things will be stored in it (eg. the passwords for
    encrypted disks is stored but the password of the KeePassX database
    is not).
  • What possibly dangerous things might be stored in it as well, without
    them asking it explicitly.

So for me it's an argument in favor or not having such an unexplainable
and potentially dangerous Persistence feature.

I mean, if we can't even know ourselves what kind of data GNOME Keyring
is storing, how can we expect our users to make a good "all-or-nothing"
decision for it?

#9 Updated by sajolida 3 months ago

  • Subject changed from Persistence saving of GNOME keyring. to Consider adding back a Persistence feature for GNOME keyring

@intrigeri: To go back to @jonathonz's initial problem which was to save typing long passwords to unlock external storage, what security difference would it make for such users to store these passwords in plaintext in their Persistence or in a KeePassX database with a much simpler simple password? I mean, what kind of security GNOME Keyring offers on top of the LUKS encryption of the Persistence (and the screen locker when the session is running)? Shoulder-surfing protection?

#10 Updated by sajolida 3 months ago

  • Target version set to Tails_3.15

#11 Updated by intrigeri 2 months ago

sajolida wrote:

intrigeri wrote:

At first glance, I strongly disagree: we ship dozens of programs that offer the user to "Save" stuff and unless the user explicitly chooses a destination file that's on the persistent volume, "saved" stuff will be forgotten next time you reboot. So I would assume that the expectation this surrounding environment creates is that "remember", as a synonym of "save", implicitly means "until I reboot". But perhaps I'm missing something behind your reasoning? I'm curious! :))) Anyway, this is probably moot because:

I understand. I think that this reveals another deeper problem which relates to a core mental model issue around Persistence.

We say "leave no trace on the computer you are using unless you ask it explicitly" when it actually means "leave no trace on the computer you are using unless you ask it explicitly to Tails".

Exactly!

FWIW, I think for our persistent stuff we try to make the consequences of choices clearer (i.e. "$thing will still be here every time you start Tails") than an ambiguous "save", but that does not solve the fundamental problem we've spotted here.

So for me it's an argument in favor or not having such an unexplainable and potentially dangerous Persistence feature.

ACK.

#12 Updated by intrigeri 2 months ago

intrigeri: To go back to @jonathonz's initial problem which was to save typing long passwords to unlock external storage, what security difference would it make for such users to store these passwords in plaintext in their Persistence or in a KeePassX database with a much simpler simple password? I mean, what kind of security GNOME Keyring offers on top of the LUKS encryption of the Persistence (and the screen locker when the session is running)? Shoulder-surfing protection?

At first glance, none compared to KeePassX, unless GNOME Keyring implements some kind of access control (e.g. an app can only access secrets it has stored there itself), which I don't know. If it's it worth me spending time researching this?

#13 Updated by sajolida 2 months ago

  • Status changed from Confirmed to Resolved
  • Assignee deleted (sajolida)

So sorry @jonathonz but, due to how blurry the impact the GNOME keyring is in Tails we won't add this feature back. Do you think that storing the passphrase in KeePassX. I understand that this mean yet-another-password for KeePassX, but since KeePassX is itself stored encrypted in Persistence, the KeePassX passphrase can be quite simpler.

#14 Updated by anonym 2 months ago

  • Target version changed from Tails_3.15 to Tails_3.14.1

Also available in: Atom PDF