Skip to contentSkip to conversation

AF_ALG algorithms required by cryptsetup

DISCUSSION Eric Biggers 2 participants 2 messages May 4

Subsystems (2)
lore
Share & tools
lore
#0 lore raw

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

#1 lore raw
Quoted 5 lines · Eric Biggers

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.

Heh, I just send reply to the thread on security list. I know about this. (It is probably waiting for moderation, cannot find link to paste here yet.)

In general, it is more complicated and need some time, but it can be done.

Quoted 3 lines

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?

For Veracrypt support, it would be easy to create list. But maybe we can do it differently completely without AF_ALG.

Quoted 10 lines

(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.

Formatting does not require root, basically only device-mapper interaction requires it now.

LUKS should be completely OK without AF_ALG (it calls userspace backend), it is about other formats.

I'll reply later.

Milan