Gnome Keyring Security

In the ongoing process of moving to a new work laptop, I have been working to protect secrets from hypothetical malware on the device.  I am using Pop!_OS 22.04 at the moment, examining the default environment: Gnome and gnome-keyring[-daemon].

Using Secrets

I had assumed, given the general focus on security in Linux, that it would be broadly similar to macOS.  To illustrate the user experience there, starting iTerm2 requires the login password to open the password manager for the first time.  The login password is also required to view the passwords through Keychain Access, regardless of whether iTerm2 is running.

I found exactly one Linux terminal with a password manager, Tilix, so of course I installed it. Within Tilix, no password is required to use the password manager.  Using Seahorse (the apparent equivalent to Keychain Access), the passwords Tilix has stored appear in the “login” keyring, unlocked by default, and no password is needed to reveal them.

In short, the keyring in Gnome is glorified plain text.  Access to the session bus is unconditional access to all secrets in all unlocked keyrings.

Who’s There?

Another major difference is that macOS seems to associate keyring entries with owners, such that each individual program gets its own settings in the OS about whether it can access particular secrets.  I can “always allow” aws-vault to access secrets in the aws-vault keyring, but I presume if awsthief tried to access them instead, I would get a new prompt.

Furthermore, if I uncheck “remember this password” on the Mac, it stays unchecked the next time the keyring is unlocked.  In Gnome, for the past 8 years, it re-checks itself every time, waiting for a moment of inattention to make the security of the alternative keyring (awsvault, of course) entirely moot.  It may be locked, but you can have D-Bus fetch the key from under the doormat.

Locking Up

I’m not certain yet whether the Gnome keyring can auto-lock collections, either.  My previous post on macOS’ security command includes how to lock the keyring after a timeout, or when the system is locked.  These capabilities are missing from Seahorse, but I haven’t fully analyzed the D-Bus interface.  (Still, I shouldn’t need to do so.)

Copying Microsoft Good Enough?

A cursory Web search suggests that the way Gnome handles the keyring is exactly like Windows.  Not only is Gnome chasing taillights, but it has chased the easiest ones to catch.

Overall, the quality of Gnome (GNU …) keyring lives up to the heuristic for bad cryptography.

Layer Juggling

Consider:

1. vim windows (Ctrl+W{w, W, h, j, k, l, ...})
2. vim tabs (gt, gT, :tab, ...)
3. screen session (Ctrl+Z ...) [because I liked Ctrl+A as beginning-of-line]
4. terminal window tabs (Ctrl+{PageUp, PageDown, Shift+PageUp, Shift+PageDown, ...})
5. application windows, e.g. other terminals (Alt+`, Alt+Shift+`) [a distinction newly required in Unity and Gnome-Shell’s defaults]
6. other applications (Alt+Tab, Alt+Shift+Tab) [may include all workspaces]
7. other workspaces (Ctrl+Alt+{↑, ↓} for gnome-shell and Unity, additionally Ctrl+Alt+{←, →} for Unity; also with Shift to drag a window with you)

My setup of Windows at work doesn’t have layers 4, 5, or 7, and it’s still too many to handle effectively.  Even if the command is right for the intent, the wrong result can still happen, for instance when I go to change window in vim and firefox closes a tab or two because it had the keyboard focus.

I get layers 2 and 3 mixed up so frequently that I typically only have tabs open in vim for a wide-ranging interface change inside my code, where I need to update model, validation, and view/controller all at once.  Each of those scopes gets a tab, and the tab is split into windows for each affected file of that particular scope.  If I have to muck around in more than two different layers at once, it gets extremely error-prone.

I think this is the reason people try to do everything inside emacs: if it’s run within a single frame, which I boldly claim is the common case, it combines layers 1 through 4 into a common framework, and leaves only layer 6 as important on the desktop.  You don’t need workspaces to tame a sprawling collection of windows anymore, because most of them are inside emacs.


Subscribe to my feed for the firehose, or check @sapphirepaw_org on twitter for stuff I deem important enough to bother telling the world about.

Race conditions, they're everywhere

Ever since I added an SSD, once in a while, gnome2 won't be able to load a random panel applet on login.  (It was a dual-core system until the slow death of I/O interfaces on the motherboard finally consumed SATA, at which point I replaced it with a quad-core board.)  That means that every now and again, I get an error similar to the following:

This OAFIID is actually relatively transparent.  Sometimes, I get ones that look more like a UUID and I ask the dialog, "How does that give me any information?"  There's not even any indication about what the error was.  (It is floating around in ~/.xsession-errors, with the helpful indication that the child didn't return an error.)

Fortunately, the answer is always the same: Don't Delete.  Things will most likely work next login.

What Would "Better" Be? PDF Reader Edition

I opened up a PDF in the default Gnome PDF reader last night, and it was once again a terrible experience.  It opened with the zoom set to "fit page width", and the scrolling set to continuous.  There's no concept of a persistent user preference, or user preferences that override the document preferences.

Then I got to considering the underlying reasons why I didn't like the default display.

Autostart in Gnome 2: the missing docs [Updated 10/10]

I've been trying to understand the autostart mechanism in Gnome 2 for a small program I'm working on.  This may continue to be a supported system in gnome-3, since it seems to be standardized by freedesktop.org and not the Gnome "Let's just rewrite around our bugs and drop features" team.

Without further ado or bitterness, here's a brief but technical dive into the modern autostart system on Gnome 2, as observed on a Lucid Lynx system (originally installed as Intrepid Ibex, I believe.)  [Updated: autostart itself is also a freedesktop standard.]