undefined

points

[-]

It doesn't seem to actually get used that way in practice. ALG_SET_KEY_BY_KEY_SERIAL didn't even appear until just a few years ago. And either way, if the interface allows you to overwrite the su binary, whether it theoretically could provide some other security benefit becomes kind of irrelevant.

by eqvinox10 hours ago|

parent|

[-]

It is being used that way:

https://github.com/opensourcerouting/frr/blob/2b48e4f97fb021...

And, sure, if it breaks system security it's pointless. But so did "dirty pipe".

I do agree the number of issues in AF_ALG is annoying, which is why I suggested a CAP_* restriction. Maybe CAP_SYS_ADMIN in init_ns, that's kinda the big hammer.

by angry_octet11 hours ago|

prev|

[-]

Better implemented as another user space process than in the kernel.

by eqvinox11 hours ago|

parent|

[-]

You can't access TPMs that way.

by angry_octet9 hours ago|

parent|

[-]

Most of the Linux kernel crypto is not touching the TPM. If there is a TPM task, only that code should be in kernel, and it should be accessed from user space by a process with the appropriate token.

by eqvinox9 hours ago|

parent|

[-]

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_octet55 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_octet54 minutes ago|

parent|

prev|

[-]

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

by kasabali7 hours ago|

parent|

prev|

[-]

Good

by eqvinox2 hours ago|

parent|