When I started using my L5, I got lured into installing gnome keyring and Seahorse, only to discover I do not like this way of doing things. Because it seemed somewhat complicated to de-install the whole thing, I stuck to it. One of the apps I have in the keyring is Authenticator. I need Authenticator to manage two factor logins I need for my work.
This worked adequately until I upgraded to Crimson. Now, when I start the Authenticator, I get an error message telling me I have to check whether I have installed a Secret Service provider like gnome-keyring, and whether there is an unlocked default keyring.
So, what I would like to do now, is get rid of the whole keyring thing, and start anew. I find remembering a couple of passwords much less of a hassle than managing the keyring(s).
Therefore my request: could somebody please help me safely uninstalling the keyring/Seahorse sh*t?
I recommend not doing that. You never know whether some application or the system itself expects Gnome keyrings to be present.
Your actual workaround is persuading whatever additional application you are using not to use a Gnome keyring i.e. to store its secrets “somewhere else”. (Then your supplementary problem becomes: was that “home brew somewhere else” implemented as securely as Gnome keyring?)
If you install an application and the only option that it offers is to store its secrets in a Gnome keyring then there is a high likelihood that if you completely obliterate the Gnome keyring functionality then the application will simply fail.
I understand your frustration when things don’t “just work”.
I would imagine that any friction that you are experiencing between flatpak and Gnome keyring is actually the system attempting to protect your security, albeit that it might not be working for you.
I don’t know what kind of two factor authentication you are talking about. If it’s just TOTP (time-based one time password, usually a 6-digit code, derived from a shared secret) then, between you and me, I would like Gnome keyring to be enhanced to provide native support for that. (Then you wouldn’t need a separate app at all and it would “just work”.)
Okay, I will not give up on gnome-keyring just yet. I have simplified and cleaned up my entries somewhat, which gave me a better insight in how it all works. Authenticator (the Belmoussaoui one) still errors out on me, though. So, it seems best to delete the app and try another one (I have installed Clockode), and setup my 2FA’s anew.
How do you suggest doing that? Button is just not active when nothing has been typed. I am quite tired of typing it again and again each time phone reboots on camera kill switch going off and on
It’s been a while since I did it last time, but typing a single character and then removing it would let you proceed with an empty password. Did something change?
What? Are you suggesting having an empty password for GNOME Keyring???
If so, that would be less secure. It is my understanding that:
By default, GNOME Keyring is authenticated with your user login. When that is the case, you are not prompted for a login for GNOME Keyring.
If you change your GNOME Keyring password, you separately get prompted for that password.
If you want to go back to default behavior, you change the password to be the same as your user login. If you change the password to an empty string, this will store your Keyring keys in plain text.
The question about whether you want an empty password or the default (see 3) is very similar to whether you want to have a passphrase when you ssh-keygen. But I absolutely wouldn’t tell someone to have an empty password for GNOME Keyring without letting people know this implication.
It’s “your” device. If “you” want to make it insecure, that is “your” right.
Assuming that you use LUKS, the considerations for how you want to encrypt any passwords that are stored in the (root) file system become different anyway.
In any case, the OP actually asked for not storing any passwords in the keyring (in which case the strength of the keyring password or otherwise becomes mostly irrelevant) and instead the OP would just remember the passwords and type them in when required.
That isn’t quite right.
You can have as many keyrings as you like, each with a unique name and each with its own password.
If you go through a desktop login-like process and the relevant PAM modules run and there is a keyring called login (and the password for that keyring matches the password used for account login) then the login keyring will automatically be unlocked.
That then cascades. If the login keyring gets unlocked at login and there are other keyrings and they store their password in the login keyring then those other keyrings will also automatically unlock.
Only the login keyring is unlocked on login in GNOME by default. Creating another keyring allows to store secrets and manually control when to unlock them instead. A straightforward way to recreate that behaviour on Librem 5 may be to install GDM to use instead of Phog. But, the last time I checked, GDM was not as convenient as Phog on Librem 5 when using a login password comprising of numbers as the default Librem 5 setup suggests. I imagine that Phog could possibly use greetd if it were installed. But it happens to be not necessary. The following additions at the end of the PAM module configuration files seem to do the trick.
Now, the login keyring is unlocked automatically after login in into Librem 5. “Authenticator” application works after login without taking a step to manually unlock the keyring.
I vaguely remember that I needed to rename my default keyring to login in the past for it to be unlocked at login, so you may also need to do this if yours is not named login.
I could only find outdated documentation about specifying pam_gnome_keyring.so in PAM. Does anyone know where I could find newer documentation?
The fact is that even as a single-user device, you could easily be convinced to run a program that would exfiltrate plain-text passwords. Similarly it’s common for web browser attacks to exfiltrate local data … would you want all of the password information saved in, say, chromium to be exfiltrated??? If you don’t think that’s a security risk even on a single-user device, I don’t know what to say. Now, most of my friends know better than to user browser-stored passwords for anything important … but at least it should be discussed.
Assuming that they are properly informed about their decision, yes. dos did not inform about the result of an empty passphrase vs. other simple alternatives.
In my opinion they should at least be told to look in ~/.local/share/keyrings/ . Some programs don’t even ask for access to store passwords in the keyring (e.g. chromium; chromium requires itself to be started up with --password-store=basic to stop it and you only know they do it when the store isn’t automatically unlocked through login and chromium/GNOMEKeyring prompts to unlock).
The last time I checked, gnome-keyring was not intended for protection from other programs. Here is a peice from another outdated documentation page. Did this change?
While it’d be nice for gnome-keyring to someday be hardened against active attacks originating from the user’s session, the reality is that the free software “desktop” today just isn’t architected with those things in mind. We need completion and integration things like the following. Kudos to the great folks working on parts of this stuff:
Trusted X (for prompting)
Pervasive use of security contexts for different apps (SELinux, AppArmor)
Application signing (for ACLs)
If I remeber correctly, some Flatpak applications has their own instances of GNOME keyring, so that some isolation could be possible with Flatpak. Key Rack application can be used to inspect secrets on the system and in Flatpak.
I imagine that a Flatpak application could be granted access to files in the user directory, where the login keyring is stored. So, a password on the login keyring would be useful if such an application is considered contained. Does it make sense? I am not sure considering how much an application with unrestricted access to configuration files in $HOME could do to circumvent the password.
Once a keyring is unlocked, I suspect that if you are “convinced to run a program” then it can exfiltrate all the passwords in any unlocked keyrings anyway.
Does a keyring password place a small extra barrier in front of the intruder in this situation? Yes.
Is it going to make any difference with a sophisticated / well-organised / well-practised / well-scripted intruder? No.
Do I personally use the Gnome keyring functionality and have a strong password on every keyring? You betcha.
brave too. Seemingly not firefox though.
Sure, that’s a likely scenario. However you can just go into seahorse and see what is automatically storing stuff in automatically unlocked keyrings.
Personally, my login keyring is the only keyring that is unlocked automatically and the only keys in that keyring are those that are put in there automatically without giving me an easy opportunity to say “no” or “somewhere else, please”. I also never ask any web browser to remember a password.
So if I were to “run a dodgy program”, I could (best case scenario) lose no passwords that are stored in keyrings. (Running a dodgy program is never a good idea though because the program can persist itself and just wait until I do unlock a keyring.)
Of course, if I have used sudo in the last X minutes (you choose X) then I just gave up /etc/shadow so that’s one hashed login password for offline cracking i.e. my own. But they’re gonna need a bigger GPU for that.
I hate the keyring. It forces me to have a much higher level of security on my device then I think I need. I don’t fully understand how to work with it. All it does is make it more difficult for me to use my own device. I am not important enough for anyone to get anything of value if they hack in to my device. I do not handle money on my Librem 5. So I don’t worry much about security. Purism has at least minimized the likelihood that my Librem 5 will be hacked.
I would wipe and reinstall the OS on my Librem 5 if I had installed the keyring. That’ll give you the default PureOS without the keyring installed. Then just don’t install it again.
I don’t have a Librem 5, but I would be surprised if you don’t have GNOME Keyring installed by default (although seahorse might not be installed by default). A few commands to explore this:
which gnome-keyring
gnome-keyring version
ls -ltr ~/.local/share/keyrings
ps aux | grep keyring
The more definitive command is apt list gnome-keyring
Not having gnome-keyring installed is not the answer - because some applications will unconditionally depend on it - and it is difficult to identify in advance which applications they are.
The right answer should be making it work better for any given user’s requirements.
It should be possible to unlock a keyring programmatically (at login) for anyone who really doesn’t care about security. That can mean just hard-coding the password in a script but if you don’t care about security, that isn’t a problem. Then a user won’t get bugged to unlock that keyring (but the keyring file will at least itself have a password - and if you are going to hard-code the password in a script then the password can be really really strong since you are never going to have to type it ).
And that should include a transparent understanding of what it does and which applications use it. Your statement about “… it is difficult to identify in advance which applications they are [that use it]” drives that point home.
Security shouldn’t have “automagical” components in my opinion.
There should be the option to have better ties to hardware security (e.g. TPM2) in my opinion. Windows, MacOS (with Secure Enclave) and Android all have this. I know that this might contradict the “automagical” component assertion … but I just don’t like it when the system seems
to be designed to hide things behind the scene. Even a notification of “key verified through …” would be useful and/or to set up those ties on installation of the tools that use them (e.g. chromium, … )
If you are unlocking a keyring programmatically (at login) then I expect that that is already achievable with Linux. But then you have to unlock the hardware element first.
(For example, if you don’t want to enter your LUKS passphrase, you can create an alternative LUKS slot that unlocks via a hardware element. The fact that it is an alternative means that if the hardware element dies or is unavailable, you can still unlock by reverting to the use of the passphrase.)
But if you are worried about “magic” then having a completely opaque hardware element (may be typical with those other platforms) is not ideal. You are putting a lot of trust in something that may be unauditable to you.
Some people complain that getting a given computer up and running requires the entry of too many PINs and passwords. For me this is definitely a security–convenience trade-off in terms of single-point-of-failure.
Yes, you can collapse the security configuration down to … user enters a PIN that unlocks the hardware element and everything else is automatically unlocked using the hardware element but if that PIN is compromised in some way or the hardware element itself is compromised, everything is compromised.
There’s a section in there on disabling the keyring. The guide tells you to remove the password from your keyring, skip the warning that this means your passwords will be stored in cleartext, then says - Hey! You don’t get prompted for a password anymore, the keyring is disabled!
Um…
from Baeldung:
If we wish, we can disable the keyring feature by removing its password.
By leaving the password blank, we disable the keyring feature
Sorry, but that isn’t how it works. They do state that doing this “raises security concerns” but don’t seem to make the connection that those concerns arise because the keyring is still enabled and doing its job, except now your passwords are stored in cleartext.
So not only do they not describe how to disable the keyring, they seem to think it’s OK to guide people to doing this without much warning.
Quite a coincidence. I have to say that I agree completely. Setting the keyring password/passphrase to empty without a warning of what this will do is just wrong. I don’t care if the person you’re describing it to claims that they don’t want to use the keyring at all. We’ve already established that a lot of people don’t even know that they are using the keyring.
