Security Policy for Kernel-Based Crypto

In this lesson, you will learn how to restrict access to kernel-level cryptographic modules to prevent unauthorized data encryption or decryption processes.

Understanding Kernel Crypto Security

The Linux Kernel Crypto API (crypto) provides high-performance cryptographic primitives directly within the kernel. While vital for disk encryption (like dm-crypt) and network security (like IPsec), these modules represent a high-value target. If a malicious process can invoke arbitrary kernel-space cryptographic operations, it could potentially bypass userspace security controls to encrypt stolen data or decrypt intercepted packets.

To harden your system, we apply Mandatory Access Control (MAC) policies—such as AppArmor or SELinux—to restrict which processes can interact with the kernel’s cryptographic interface.

Implementing Access Restrictions

Access to the kernel's crypto engine is generally controlled through specific files within the /proc/ and /sys/ virtual file systems, and more importantly, via the AF_ALG socket family. The AF_ALG socket allows userspace applications to offload cryptographic operations to the kernel.

To secure this, your MAC policy should follow the principle of least privilege:

1. Identify legitimate actors: Only specific services (like systemd-cryptsetup or strongswan) should have the capability to create af_alg sockets.
2. Restrict socket usage: Ensure your security profiles explicitly deny access to af_alg for standard user applications.

For example, in an AppArmor profile, you can restrict the creation of these sockets:

# Deny all crypto socket creation by default
deny network alg,

# Explicitly allow only for the trusted daemon
/usr/sbin/trusted-crypto-daemon {
  network alg,
  ...
}

Why Granularity Matters

If you grant global access to the kernel crypto API, you essentially permit any process to utilize your CPU’s hardware-accelerated encryption instructions (like AES-NI). By limiting this access, you force applications to rely on less privileged or audited userspace libraries, or you ensure that only verified system components perform sensitive cryptographic transformations. Monitoring the audit logs for AF_ALG socket denials is a critical step in verifying that your policy is effectively isolating your kernel's crypto subsystem.

Key Takeaway: Secure kernel-level cryptography by restricting AF_ALG socket access via MAC policies, ensuring only authorized system services can interact with the kernel's cryptographic engine.