undefined

points

[-]

Yes, AF_ALG is exposing too many things, like authencesn, which has zero reason for being userspace accessible. It's a crypto mode specific to IPsec.

However,

> it should be accessed from user space by a process with the appropriate token.

That is AF_ALG. The operations it offers are what you need for full coverage. The issues with it are two:

- usage specific crypto in the kernel implements the same interfaces, and it doesn't have a filter for that, as mentioned above. It's not offering too many operations, it's offering too many algorithms.

- it's trying to be fast. I guess people also want to use crypto accelerators through it. (Which is kinda related to TPMs, there is accelerator hardware with built-in protected key storage...)

The CVE we're looking at here is in the intersection of both of these.

by angry_octet3 hours ago|

parent|

[-]

All the uses of vmsplice etc are a bit tricky, and that points to the need for a better interface. But given you're using splice, why not do the crypto in user space? A belief that it is better to be fast and buggy than safe and slower?

by eqvinox2 hours ago|

parent|

[-]

If neither a hardware component nor kernel key management is involved, crypto should be done in userspace, end of sentence.

The more I think about it, the more I think it should be behind CAP_SYS_ADMIN, or a new CAP_KCRYPT (better name TBD. CAP_CRYPT_OFFLOAD?)

by angry_octet56 minutes ago|

parent|

[-]

Yes it should definitely require a capability.

Still a risk that some admin-enabled method (like enabling an IPsec VPN) provides a path to it, but would reduce the potential for crafting weird inputs.

by angry_octet55 minutes ago|

parent|

prev|

[-]

I'm also wondering if it couldn't be rewritten to use io_uring interfaces.