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

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Jun 23, 2026 at 01:24:01PM -0400, Demi Marie Obenour wrote:
> I think there is room for something in-between the allowlist provided
> here and "no restrictions".  For instance, I think it makes sense
> to have a mode that allows modern¸ widely-used algorithms (AES-GCM,
> ChaCha20-Poly1305, SHA-3, HMAC, etc) to all users.
> 
> This makes it less likely someone turns off all restrictions.

Would it be worth the complexity when AF_ALG as a whole is deprecated?

> XFRM allows providing an arbitrary algorithm name, and it appears to
> be accessible in unprivileged user namespaces.  That also needs an
> allowlist.

Doesn't XFRM have a fixed list already?  The algorithm comes in as a
string, but it has to be in the list.

> > +	{ "hmac(sha512)", true }, /* iwd, sha512hmac */
> 
> Should this entry have privileged = false?  sha512hmac doesn't
> need privileges.

It's for the FIPS 140-3 integrity check use case, which runs as root.

> > diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
> > index 4dfe7899f8fa..bd522915d56d 100644
> > --- a/crypto/algif_rng.c
> > +++ b/crypto/algif_rng.c
> > @@ -48,10 +48,14 @@
> >  
> >  MODULE_LICENSE("GPL");
> >  MODULE_AUTHOR("Stephan Mueller <smueller@chronox.de>");
> >  MODULE_DESCRIPTION("User-space interface for random number generators");
> >  
> > +static const struct af_alg_allowlist_entry rng_allowlist[] = {
> > +	{},
> > +};
> 
> Can this whole file be deleted?  You wrote that it isn't actually used.

That's not quite what I said.  There's still one known use case: CAVP
testing for FIPS 140-3 certifications.  But that only accesses the drbg
and jitterentropy RNGs and can run as root.

We could consider deleting it anyway and require that the FIPS people
use custom kernel modules.  But that is out of the scope of this patch.

> > +static const struct af_alg_allowlist_entry skcipher_allowlist[] = {
> > +	{ "adiantum(xchacha12,aes)", false }, /* cryptsetup */
> > +	{ "adiantum(xchacha20,aes)", false }, /* cryptsetup */
> > +	{ "cbc(aes)", true }, /* iwd */
> > +	{ "cbc(des)", true }, /* iwd */
> > +	{ "cbc(des3_ede)", true }, /* iwd */
> > +	{ "ctr(aes)", true }, /* iwd */
> > +	{ "ecb(aes)", true }, /* iwd, bluez */
> > +	{ "ecb(des)", true }, /* iwd */
> > +	{ "hctr2(aes)", false }, /* cryptsetup */
> > +	{ "xts(aes)", false }, /* cryptsetup benchmark */
> > +	{},
> > +};
> 
> Do the cryptsetup ones really need to be accessible to unprivileged users?

If we don't allow them, people running 'cryptsetup benchmark' will
notice the change.  Formatting could also be affected.

Requiring sudo in these cases might be feasible, but we need to strike
the right balance.  Maybe Milan has an opinion.

- Eric