Linux Keyring

The Linux keyring is a kernel-managed secure storage for cryptographic keys, credentials, and secrets. Unlike storing keys in files, kernel keyring entries live in kernel memory — no disk access, protected from other processes, automatically cleaned up when sessions end. Used by Kerberos, WiFi authentication, dm-crypt, and container registries.

Keyring Types

KeyringScopeLifetimeUse case
threadOne thread onlyThread lifetimeThread-local credentials
processOne processProcess lifetimeProcess-local secrets
sessionLogin sessionSession lifetimeLogin credentials (Kerberos tickets)
userOne UIDWhile any process with UID existsUser-wide persistent secrets
user-sessionOne UIDSession lifetimeDefault if no session keyring
persistentOne UIDConfigurable timeoutKerberos ccache

Using the Keyring with keyctl

# List your keyrings: keyctl show # Session Keyring # -3 --alswrv 0 0 keyring: _ses # 938 --alswrv 0 65534 \_ keyring: _uid.1000 # 456 --als-rv 1000 1000 \_ user: my_secret # Add a key to your session keyring: keyctl add user my_api_key "super-secret-value-here" @s # Returns a key ID # Read a key: keyctl print KEY_ID # List keys in session keyring: keyctl list @s # Revoke a key (immediately unavailable): keyctl revoke KEY_ID # Set key timeout (auto-expire): keyctl timeout KEY_ID 3600 # expire in 1 hour # Link key to another keyring: keyctl link KEY_ID @u # link to user keyring # Unlink (remove from keyring): keyctl unlink KEY_ID @s

How the Kernel Uses Keys

What does the kernel itself use the keyring for? The kernel uses keyrings for disk encryption (dm-crypt/LUKS decryption keys stored in-kernel), NFS Kerberos authentication (krb5 tickets), CIFS/Samba credentials, and module signing verification (the kernel's trusted keyring holds public keys used to verify module signatures). These are kernel-internal uses you don't manage directly.
# View the kernel's trusted key store: keyctl show %:.builtin_trusted_keys # Shows X.509 certificates of trusted CA keys baked into the kernel # Used to verify module signatures and Secure Boot # LUKS uses a key from the kernel keyring: # When you unlock a LUKS volume, the decryption key is stored in the kernel # /proc/keys shows which keys exist: cat /proc/keys # KEY_ID EXPIRY TYPE DESC FLAGS PERM UID GID DESC # CIFS (Samba) credentials in the session keyring: # mount.cifs stores credentials as keys of type "cifs.spnego"

Applications Using the Keyring

# GNOME Keyring (user-space layer over kernel keyring + encrypted wallet) # Stores: WiFi passwords, SSH keys, app passwords secret-tool store --label='My Password' service myapp username alice secret-tool lookup service myapp username alice # Docker credential store using the keyring: # /etc/docker/config.json: {"credsStore": "secretservice"} # docker login - credentials go to keyring, not plaintext config # Python: access kernel keyring via keyring library # pip install keyring # import keyring # keyring.set_password("myservice", "alice", "s3cr3t") # password = keyring.get_password("myservice", "alice") # Kerberos ticket stored in keyring: kinit alice@REALM.COM klist # shows current Kerberos tickets keyctl show # session keyring contains krb5 ticket

Frequently Asked Questions

What will I learn here?

This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.

How should I use this page?

Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.

What should I read next?

Use the navigation below to continue to the next lesson or explore related topics.