libcrypto failure on Openssh
Hareesh Das Ulleri
hareesh.ulleri at ovt.com
Wed Mar 1 01:29:13 UTC 2023
From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of Michael Wojcik via openssl-users
Sent: Tuesday, February 28, 2023 10:39 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: Monday, 27 February, 2023 23:15
> Sorry for the confusion. This is during OpenSSH authentication, a
> child process which does not have any privileges (e.g. file open) and
> it is supposed to do the authentication, that means it calls Libcrypto
> Cipher functions. In this case even file reopen won't work since process has no privileges to do this.
> Is it mentioned or anyone attempted how OpenSSL supposed to handle
> this case ?
OpenSSL isn't. This is your problem. Your provider has a limitation which prevents it from working in certain use cases.
The obvious fix is to correct the permissions on your device node so it can be opened by the unprivileged process.
There are other possibilities (e.g. descriptor passing), but generally they introduce complexity for little or no additional security.
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.
More information about the openssl-users