Bug 3492 - Allow changing allowed_providers via config file
Summary: Allow changing allowed_providers via config file
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: Smartcard (show other bugs)
Version: -current
Hardware: All All
: P5 enhancement
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-10-29 02:19 AEDT by PaulA
Modified: 2023-02-10 13:40 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description PaulA 2022-10-29 02:19:37 AEDT
Our company is developing HSM and library that implements the PKCS#11 standard. Our clients use these solutions, including work with OpenSSH.

Our PKCS#11 library is distributed in the usual way for Linux-based OS: they are installed in /opt/<company name>/ and symbolic links are created in /usr/lib/. Paths to libraries are registered by using ldconfig.

We encountered difficulties with the need of having loadable providers in /usr/lib/ or /usr/local/lib/ by their real so-libraries (not symbolic links). These settings can be changed at the building stage of OpenSSH, but OpenSSH packages contain default values in various repositories. In addition, developers of opensc-pkcs11 faced the same problem and they now are duplicating installed libraries in several places as a solution.

Was the introduction of allowed_providers a solution of CVE-2016-1009? 
We would like to suggest you to allow changing allowed_providers via config file in /etc/. This change would add flexibility to the product configuration and still prevent an untrustred provider from running (if modifying the configuration file requires the same rights as adding the provider to the predefined directories). Also, this change will allow you to install providers in isolated directories and register them to work with OpenSSH without unnecessary copies or rebuilds of OpenSSH.
Comment 1 Damien Miller 2023-02-10 13:40:02 AEDT
ssh-agent doesn't have a configuration file and we're not inclined to add one for a single option.

If the default allowlist is missing customary paths for loadable modules then we're willing to add them though.