Re: [PATCH] crypto: af_alg - Add af_alg_restrict sysctl, defaulting to 1

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jun 23, 2026 at 10:09:27PM -0400, Demi Marie Obenour wrote:
> 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 <ebiggers@kernel.org> 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@gmail.com/).
> >>>
> >>> 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)

I think the following is what you're asking for:

    sysctl crypto.algif_aead_priv_allowlist='ccm(aes)'
    sysctl crypto.algif_aead_unpriv_allowlist=''
    sysctl crypto.algif_hash_priv_allowlist='cmac(aes),hmac(md5),hmac(sha1),hmac(sha256),hmac(sha384),hmac(sha512),md4,md5,sha224,sha256,sha384,sha512'
    sysctl crypto.algif_hash_unpriv_allowlist='sha1'
    sysctl crypto.algif_skcipher_priv_allowlist='cbc(aes),cbc(des),cbc(des3_ede),ctr(aes),ecb(aes),ecb(des)'
    sysctl crypto.algif_skcipher_unpriv_allowlist='adiantum(xchacha12,aes),adiantum(xchacha20,aes),hctr2(aes),xts(aes)'
    sysctl crypto.algif_rng_priv_allowlist=''
    sysctl crypto.algif_rng_unpriv_allowlist=''

We could do that if it's what people want.  Just keep in mind that it
would be much more complex than the single tristate sysctl.  And in
practice the number of people who are knowledgeable enough to create
these lists is quite small; we've seen similar things with other "Crypto
API" configuration knobs that seem to never be touched in practice.

Any thoughts?

- Eric