On Mon, Jun 22, 2026 at 4:49 PM Eric Biggers <[email protected]> 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/[email protected]/). > > 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"?
