AF_ALG algorithms required by cryptsetup

[Eric Biggers <ebiggers@kernel.org>]

Hi Milan,

AF_ALG is going to have to go away eventually, due to its frequent
vulnerabilities which vastly outweigh its benefits.  Userspace crypto
code can be, should be, and generally already is used instead.

In the meantime, AF_ALG will need to be hardened by reducing its attack
surface, for example by removing unneeded algorithms and/or adding a
privilege check.

I understand cryptsetup actually already links to a userspace crypto
library such as libcrypto or libgcrypt by default (more than one is
supported).  However, it sometimes falls back to AF_ALG for certain
algorithms for password hashing or keyslot encryption.  The default
settings don't seem to use it (indeed, I use LUKS on one of my systems
and AF_ALG isn't enabled in my kernel), but some non-default settings
seem to use it.

Is a reasonably definitive list of the algorithms cryptsetup needs from
AF_ALG available anywhere, so that an allowlist can be implemented on
the kernel side?

(It would need to be unioned with what iwd uses as well.)

Also, what are the biggest blockers to removing the AF_ALG dependency
from cryptsetup, in your view?

Finally, how well would a CAP_SYS_ADMIN or CAP_NET_ADMIN restriction
work for cryptsetup?  IIUC, volume formatting and opening require root
anyway, and all the device-mapper ioctls already require CAP_SYS_ADMIN.
I know 'cryptsetup benchmark' would be affected, but that tends to be a
one-off manually-run thing, which people could add 'sudo' to.

- Eric