libcrypto failure on Openssh

[Michael Wojcik]

> From: Hareesh Das Ulleri <hareesh.ulleri at ovt.com>
> Sent: Tuesday, 28 February, 2023 18:29
> 
> This is not device issue. It's how OpenSSH behave during authentication
> process, called privileged separation. In this an unprivileged child process
> won't have any privilege to open any file descriptor and also all the file
> descriptors were already closed.
> 
> If Libcrypto want to use a hardware accelerator cryption, the process cant
> able to open the fd even the device has permission for all process. Not sure
> how OpenSSL handles this case.

Then it's an OpenSSH problem. It's still not an OpenSSL one. What do you think OpenSSL could do about it? Why do you think it's OpenSSL's responsibility to "handle[] this case"? It's between what your provider requires (which, now that you've clarified it, is sensible) and what OpenSSH does (which only makes sense if cryptographic operations are being performed exclusively with the main CPU).

You need to take this up with the OpenSSH developers. I took a quick look at recommendations for using other HSMs with OpenSSH, but the ones I found used ssh-agent to perform signing operations (via ssh-add -S) and perform other cryptographic operations on the main CPU rather than using the HSM.

Privilege separation can be disabled in sshd. though that's a rather coarse solution.

Personally, my inclination would be to fix OpenSSH, and add a configurable mechanism for retaining the open device fd in the unprivileged child, or for specifying paths the child is allowed to open. I looked at the UMich CITI website on OpenSSH privilege separation (http://www.citi.umich.edu/u/provos/ssh/privsep.html) and the original USENIX paper, and it seems Provos et al. simply failed to consider the case of offloaded cryptographic operations. This is a design failure in the OpenSSH privsep model and should be corrected by the OpenSSH maintainers, and it's likely the easiest way to do that is to fix it and submit a pull request. (That said, I've never worked with the OpenSSH maintainers, and I don't know how accommodating they are.)

-- 
Michael Wojcik