libcrypto failure on Openssh

[Hareesh Das Ulleri]

Thanks for the detailed explanation on OpenSSH and suggestion even though seeking help on HSM implementation via OpenSSL custom provider. 

In this case, Does OpenSSL provider support HSM via kernel Crypto API?  If so, is there any docs or e.g. available on OpenSSL provider interfaces to Cryptodev?

Thank you for any help...

Regards,
Hareesh


-----Original Message-----
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael Wojcik via openssl-users
Sent: Wednesday, March 1, 2023 10:55 PM
To: openssl-users at openssl.org
Subject: RE: libcrypto failure on Openssh

[CAUTION]: EXTERNAL EMAIL


> 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 (https://urldefense.com/v3/__http://www.citi.umich.edu/u/provos/ssh/privsep.html__;!!AYUVhIwY!8G73lXOgA_TqLX-iAOz3XeNafMpfl_ctH9tES51EqDPVWzLU70ilqOOwzX04swbqjCdGbmtzhkEFZl64VqwMJN4Myw$ ) 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