Kerberos Security: Kernel Keyring vs File Caches

G5 Cyber Security

2 weeks ago

TL;DR

Using the Kernel Keyring for Kerberos tickets on Linux is generally more secure than relying on default file-based caches. It protects against user space processes accessing your tickets and offers better integration with system security features.

Understanding the Problem

Kerberos stores authentication tickets, which are like digital passports allowing you to access network services without repeatedly entering passwords. By default, Linux typically saves these tickets in files owned by the user (e.g., /tmp/krb5cc_*). This has security implications because any process running with that user’s permissions can potentially read and use those tickets.

Why Kernel Keyring is Better

The Kernel Keyring stores Kerberos tickets in the kernel’s memory space, offering several advantages:

Improved Access Control: Only processes with specific capabilities (usually root) or those explicitly granted access can read from the keyring. This significantly reduces the risk of malicious software stealing your credentials.
Reduced Persistence on Disk: Tickets are primarily held in memory, minimising the window for offline attacks against cached ticket files.
Better Integration with System Security: The Kernel Keyring integrates well with system-wide security features like SELinux and AppArmor.

Setting up Kerberos to Use the Kernel Keyring

Here’s how to configure your system:

Step 1: Check Current Configuration

First, determine where your current Kerberos tickets are stored. Run:
```
klist -c
```
This will show you the cache name (e.g., FILE:/tmp/krb5cc_1000).

Step 2: Configure Kerberos

Edit your Kerberos configuration file, usually located at /etc/krb5.conf or ~/.krb5.conf. Add the following line to the [libdefaults] section:
```
default_tkt_enctypes = aes256-cts-hmac-sha1-md5
```
(Adjust encryption types as needed for compatibility, but AES is recommended.)
Add the following line to the [libdefaults] section:
```
default_tkt_storage = krb5kcm
```
This tells Kerberos to use the Kernel Keyring.

Step 3: Restart Kerberos Services

Restart your Kerberos services to apply the changes. The exact command depends on your distribution:
- Systemd (most modern distros):
```
sudo systemctl restart krb5-kdc
```
  and
```
sudo systemctl restart krb5-admin-server
```
- SysVinit:
```
sudo service krb5-kdc restart
```
  and
```
sudo service krb5-admin-server restart
```

Step 4: Verify the Configuration

Obtain a new Kerberos ticket:
```
kinit your_username@YOUR.REALM
```
Check the cache again:
```
klist -c
```
The cache name should now be something like KCM:your_username@YOUR.REALM, indicating it’s stored in the Kernel Keyring.

Important Considerations

Root Access: Processes needing access to Kerberos tickets will require appropriate capabilities or root privileges. This is a security feature, not a bug!
Reboot Persistence: Tickets are lost on reboot unless you use a persistent keyring service (see below).

Making Tickets Persistent Across Reboots

By default, tickets in the Kernel Keyring aren’t saved across reboots. To address this:

kcm-cache: Some distributions provide a service like kcm-cache which automatically saves and restores tickets on boot. Check your distribution’s documentation for details.