Hardening the GNOME desktop (dconf)

The threat: the desktop session is where phishing lands

A workstation is a favourite foothold: a phishing click or a malicious document runs in the user's desktop session. From there, weak desktop defaults help the attacker: automatically mounting and auto-running removable media (the classic USB-drop), an unlocked screen on an unattended machine, or a GDM login that enumerates every username for an attacker to spray. And because these are user settings, a normal user (or code running as them) can usually flip them back.

Why harden it

Desktops are where humans, and therefore phishing and removable media, meet the network. Hardening GNOME shrinks that surface and, crucially, locks the safe settings system-wide so they cannot be reverted per user. The desktop becomes a controlled, predictable baseline rather than 200 differently-configured machines.

How dconf enforcement works

dconf is a layered settings store, and the security comes from the system database plus locks, not from per-user keyfiles:

1. A profile (/etc/dconf/profile/user) tells each session to read a system database under the user's own: user-db:user then system-db:local.
2. Keyfiles under /etc/dconf/db/local.d/ set the hardened values (INI-style, grouped by schema path).
3. Lock files under /etc/dconf/db/local.d/locks/ list the keys a user may read but not override. This is what turns a suggestion into enforcement.
4. dconf update compiles the text keyfiles into the binary database. Nothing applies until you run it.

# /etc/dconf/db/local.d/00-security
[org/gnome/desktop/screensaver]
lock-enabled=true
lock-delay=uint32 5
[org/gnome/desktop/session]
idle-delay=uint32 300
[org/gnome/desktop/media-handling]
automount=false
automount-open=false
autorun-never=true

# /etc/dconf/db/local.d/locks/00-security
/org/gnome/desktop/screensaver/lock-enabled
/org/gnome/desktop/media-handling/automount

Then dconf update. For the GDM greeter, set org.gnome.login-screen disable-user-list=true and banner-message-enable=true with banner-message-text, and disable any guest session.

Defense principles applied

• Secure defaults: disable automount/automount-open and set autorun-never; enable the screen lock with a short idle delay; show the login banner; hide the user list at GDM.
• Enforce, don't suggest: back each setting with a dconf lock so a user can read but not override it.
• Accountability: a warning banner at the GDM login screen states monitored, authorized access.

What Pavois audits: the effective dconf database

Pavois reads the effective dconf database (the resolved value a session actually gets, not just a keyfile), so it sees system defaults and locks as GNOME applies them. Across its GNOME/dconf rules it checks: the GDM login banner enabled and its message text, removable-media automount/automount-open disabled and autorun-never set, the idle screen lock enabled with a bounded delay, and that each is locked so users can't undo it.

Verify

# the resolved value the session gets:
dconf read /org/gnome/desktop/screensaver/lock-enabled    # true
gsettings get org.gnome.desktop.media-handling automount  # false
# is it locked? a locked key cannot be changed by the user:
dconf write /org/gnome/desktop/screensaver/lock-enabled false  # fails / no effect when locked
machinectl shell user@ -- gsettings get org.gnome.login-screen disable-user-list

Pitfalls

• Forgetting dconf update: edits to keyfiles do nothing until the binary database is recompiled.
• Setting without locking: a value the user can change back is not hardening. Add the matching entry under locks/.
• No profile, no system db: if /etc/dconf/profile/user doesn't reference system-db:local, the keyfiles are never read.
• Type matters: uint32 300, true/false, quoted strings; a wrong type makes the key silently ignored.
• Headless servers don't run GNOME: these controls apply to workstations; they are not relevant on a server without a desktop.

FAQ

Why lock the keys instead of just setting them? Because dconf values are user-writable by default; without a locks/ entry the user (or malware in the session) reverts them. The lock makes the system value authoritative.

My keyfile change had no effect. You likely skipped dconf update, or the user profile doesn't include system-db:local. Check both.

Why does Pavois read the resolved value, not the keyfile? Because layering and locks decide what a session actually receives; the effective database is the truth, a keyfile on disk is only an input.