Description of problem:
At the moment if you want to (eg) ssh to a particular host that
uses legacy crypto, or upgrade RPM packages which use SHA1 signatures,
or connect to an old HTTPS server with Firefox, then the easiest
way to describe this to a customer is to use the big hammer:
# update-crypto-policies --set LEGACY
This of course downgrades security for the whole system.
The alternative is to use service-specific voodoo. eg. the
right way to do this for ssh to a host happens to be:
(Actually I'm not sure that is true, I have read differing advice
on this. Even if this works now, will it continue to work in future?)
This bug is a request that somehow we make this easier.
Version-Release number of selected component (if applicable):
Triaging as low priority because while there's no arguing it'd be a well sought-after feature,
it's also nigh impossible to implement, as it'd be a complete reimagining of what crypto-policies do
and even then would entail patching just about every other component that'd gonna make use of
whatever the solution might be.
Out of the backends we have, only SSH ones expose per-host configuration.
None of the libraries have a per-service configuration mechanism per se.
The scope of crypto-policies is to provide system defaults decoupled from the backends themselves,
and this is well outside this scope.
See also BZ #2069733 related to vsftpd.
In this scenario, the customer wants to restrict the ciphers for TLS1.3 just for vsftpd service, not globally.
I found a way but it's hacky.
(In reply to Alexander Sosedkin from comment #3)
> Triaging as low priority because while there's no arguing it'd be a well
> sought-after feature,
> it's also nigh impossible to implement, as it'd be a complete reimagining of
> what crypto-policies do
> and even then would entail patching just about every other component that'd
> gonna make use of
> whatever the solution might be.
So maybe I'm crazy, but it really feels like we're making this too hard. AFAICT, all of the "magic" performed by update-crypto-policies involves modifying files and symlinks in /etc/crypto-policies. If that's the case, is there any reason that some sort of "runcp" wrapper couldn't be created that uses a mount namespace to run a command with the desired policy (similar to SELinux's runcon command)?
* Create a new mount namespace.
* Create a private copy of /etc/crypto-policies. (overlayfs could also work here, but that would get weird if the system-wide
policy were modified.)
* Bind mount the private copy at /etc/crypto-policies.
* Run update-crypto-policies to set the desired policy (which will modify the private copy).
* Run the desired command.
* Clean up the private copy.
There are obviously additional details, such as privilege escalation and de-escalation, but these are well known patterns at this point.
What am I missing?
> new mount namespace
For crypto libraries that allow redefining the config location, a mount namespace sounds like an overkill when an envvar would work.
> What am I missing?
For per-application configuration: wrapping each and every application with some wrapper in a system that lacks a concept of applications.
For service configuration: no doubt it's possible somehow, but then for services there usually already are exposed controls like priority strings that do it in an existing distribution-agnostic way. And if you go with a per-systemd-service override, I'd say the first question to solve is what'd be the interface for opting into it.
For per-host configuration, which sounds like the best scope for relaxing the policy, that sounds like it will need invasive library support and will have to be discussed upstream first.
(In reply to Alexander Sosedkin from comment #6)
> For crypto libraries that allow redefining the config location, a mount
> namespace sounds like an overkill when an envvar would work.
Sure, but the idea is to create a tool that will work as broadly as possible.
> For per-application configuration: wrapping each and every application with
> some wrapper in a system that lacks a concept of applications.
I'm thinking of a simple utility that can be invoked from the command line,
so the "application" is whatever the user is running from their shell.
> For service configuration: no doubt it's possible somehow, but then for
> services there usually already are exposed controls like priority strings
> that do it in an existing distribution-agnostic way. And if you go with a
> per-systemd-service override, I'd say the first question to solve is what'd
> be the interface for opting into it.
Honestly, I was thinking about clients (SSH, web browsers, etc.), rather than
services. I think that running a service with reduced security is a much more
significant decision than a one-off SSH or browser invocation, and it isn't
really the use case that I had in mind. (AFAICT, "service" in the bug summary
refers to a service to which one is connecting, not a service that one is
> For per-host configuration, which sounds like the best scope for relaxing
> the policy, that sounds like it will need invasive library support and will
> have to be discussed upstream first.
Per-host configuration is definitely ideal in some cases, but not in others.
Consider 2 newly installed network switches that only support older SSH ciphers.
* Switch 1 doesn't support newer ciphers at all. It's stuck with the old ones,
even with the latest NOS. A persistent, per-host configuration fits this case.
* Switch 2 just needs to have its latest NOS update installed to support the newer
ciphers. In this case, the persistent configuration is overkill; I just want to
allow the older ciphers for a single invocation of SSH.
(SSH is probably a bad example, because it already supports both per-host configuration
and command-line options, but you get the idea.)
Created attachment 1881660 [details]
Proof of concept "wrapper" to run a command with a specified crypto policy
Attaching a proof of concept "wrapper," which runs a command with the specified crypto policy.
* Build with 'gcc -O3 -Wall -Wextra -o runcp runcp.c -lcap-ng'.
* It needs CAP_SYS_ADMIN, so add the file capability -
'sudo setcap cap_sys_admin=p' runcp'. (Note that /tmp is mounted nosuid,
which makes file capabilities not work; ask me how I know.)
* Run a command with a different policy, e.g. './runcp legacy bash'.
I've set up a web server that only supports TLSv1. If I try to connect to it from a system running Fedora 36 with the DEFAULT crypto policy, I am unable to connect because of the TLS version.
$ curl -ksvI https://172.31.253.195
* Trying 172.31.253.195:443...
* Connected to 172.31.253.195 (172.31.253.195) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* TLSv1.0 (OUT), TLS header, Certificate Status (22):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS header, Unknown (21):
* TLSv1.3 (IN), TLS alert, protocol version (582):
* error:0A00042E:SSL routines::tlsv1 alert protocol version
* Closing connection 0
With the wrapper, I'm able to successfully connect.
$ runcp legacy curl -ksI https://172.31.253.195
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
HTTP/1.1 403 Forbidden
Date: Fri, 20 May 2022 21:14:38 GMT
Server: Apache/2.4.53 (Fedora) OpenSSL/1.1.1n
Last-Modified: Fri, 26 Mar 2021 17:49:58 GMT
Content-Type: text/html; charset=UTF-8
Created attachment 1881663 [details]
Corrected version of wrapper (fixed typo)
Thank you for your interest and your contribution.
We've discussed the approach and our first impression is that
we're uneasy with shipping a privileged wrapper
to achieve a goal that should theoretically be solveable
with just setting envvars to point backends at different configuration files.
Not all of them currently support that,
but patching the remaining ones isn't infeasible.
Maybe even to accept just a policy name for a more unified interface.
That's not to diminish the value of your wrapper as it is now,
I can totally see it as a useful testing tool.
In fact, I'm open to making a copr with it
if you would kindly license it under LGPL-2.1-or-later
or another free license of your choice,
so that we have a stop-gap solution for the RFE
until we have a way we'd agree to support.
(note to self, --no-reload is also needed)
(In reply to Alexander Sosedkin from comment #10)
> That's not to diminish the value of your wrapper as it is now,
> I can totally see it as a useful testing tool.
> In fact, I'm open to making a copr with it
> if you would kindly license it under LGPL-2.1-or-later
> or another free license of your choice,
> so that we have a stop-gap solution for the RFE
> until we have a way we'd agree to support.
Happy to add a license. Is a new attachment with an SPDX tag sufficient?
(In reply to Alexander Sosedkin from comment #11)
> (note to self, --no-reload is also needed)
Aha! That explains why I sometimes get those policy kit pop-ups asking for authorization to start services. I'll add that.
> Happy to add a license. Is a new attachment with an SPDX tag sufficient?
Yes, more than.
> I'll add that.
And I'll publish it the next day; gotta run today, but I've reached the point of `packit local-build` building a working package.
Created attachment 1883508 [details]
Attaching updated wrapper. Added SPDX license header (GPL 3.0 or later) and added --no-reload option to update-crypto-policies invocation.
Published at https://gitlab.com/redhat-crypto/crypto-policies-extras
Built in COPR at https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras