On 6/23/26 15:27, Eric Biggers wrote: > On Tue, Jun 23, 2026 at 12:12:24PM -0700, Andy Lutomirski wrote: >> 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"? > > If we want to offer more settings we could. I could see this getting > quite complex pretty quickly once everyone weighs in, though. There's > quite a bit of value in keeping things simple, even if the offered > settings won't be optimal for every case. > > - Eric
What about exposing both allowlists to userspace and making them configurable? I'm mostly concerned about systems running code (possibly closed-source) that uses algorithms that nobody here knows about. It would be better to allow a single algorithm than to turn off all restrictions. -- Sincerely, Demi Marie Obenour (she/her/hers)
OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
