Re: [PATCH] crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1
From: Andy Lutomirski
Date: Tue Jun 23 2026 - 15:13:02 EST
On Mon, Jun 22, 2026 at 4:49 PM Eric Biggers <ebiggers@xxxxxxxxxx> wrote:
>
> AF_ALG is a frequent source of vulnerabilities and a maintenance
> nightmare. It exposes far more functionality to userspace than ever
> should have been exposed, especially to unprivileged processes. Recent
> exploits have targeted kernel internal implementation details like
> "authencesn" that have zero use case for userspace access.
>
> Fortunately, AF_ALG is rarely used in practice, as userspace crypto
> libraries exist. And when it is used, only some functionality is known
> to be used, and many users are known to hold capabilities already.
> iwd for example requires CAP_NET_ADMIN and has a known algorithm list
> (https://lore.kernel.org/linux-crypto/bcbbef00-5881-421b-8892-7be6c04b832d@xxxxxxxxx/).
>
> Thus, let's restrict the set of allowed algorithms by default, depending
> on the capabilities held.
>
> Add a sysctl /proc/sys/crypto/af_alg_restrict with meaning:
>
> 0: unrestricted
> 1: limited functionality
> 2: completely disabled
>
> Set the default value to 1, which enables an algorithm allowlist for
> unprivileged processes and a slightly longer allowlist for privileged
> processes.
In our brave new world of containers, this is a bit awkward. The
admin is sort of asking two separate questions:
1. Is the actual running distro and its privileged components capable
of working without AF_ALG or with only the parts marked as being
unprivileged?
2. Is the system running contains that need the unprivileged parts?
(Which is maybe just sha1 for ip? I really don't know.)
Should there maybe be two separate options so that all options are
available? Or maybe something between 2 and 3 that means "limited
functionality and privileged modes are completely disabled"?