Bug 2064740 - RFE: Make it easier to configure LEGACY policy per service or per host
Summary: RFE: Make it easier to configure LEGACY policy per service or per host
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: crypto-policies
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: ---
Assignee: Alexander Sosedkin
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-03-16 13:08 UTC by Richard W.M. Jones
Modified: 2022-08-04 10:04 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)
Proof of concept "wrapper" to run a command with a specified crypto policy (3.03 KB, text/plain)
2022-05-20 21:15 UTC, Ian Pilcher
no flags Details
Corrected version of wrapper (fixed typo) (3.03 KB, text/plain)
2022-05-20 21:37 UTC, Ian Pilcher
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat-crypto/crypto-policies-extras 0 None None None 2022-05-26 09:34:21 UTC
Red Hat Issue Tracker CRYPTO-7174 0 None None None 2022-05-09 20:56:54 UTC
Red Hat Issue Tracker RHELPLAN-115738 0 None None None 2022-03-16 13:14:50 UTC

Description Richard W.M. Jones 2022-03-16 13:08:15 UTC
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:

 .ssh/config ---
 Host old-host
   KexAlgorithms diffie-hellman-group1-sha1

(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):

crypto-policies-20220223-1.git5203b41.el9.noarch

Comment 3 Alexander Sosedkin 2022-03-16 13:20:50 UTC
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.

Comment 4 Renaud Métrich 2022-03-29 15:32:45 UTC
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.

Comment 5 Ian Pilcher 2022-05-06 19:44:52 UTC
(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?

Comment 6 Alexander Sosedkin 2022-05-09 08:23:54 UTC
> 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.

Comment 7 Ian Pilcher 2022-05-09 20:55:14 UTC
(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
running locally.)

> 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.)

Comment 8 Ian Pilcher 2022-05-20 21:15:26 UTC
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
ETag: "211a-5be742910bd80"
Accept-Ranges: bytes
Content-Length: 8474
Content-Type: text/html; charset=UTF-8

Comment 9 Ian Pilcher 2022-05-20 21:37:38 UTC
Created attachment 1881663 [details]
Corrected version of wrapper (fixed typo)

Comment 10 Alexander Sosedkin 2022-05-25 11:32:59 UTC
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.

Comment 11 Alexander Sosedkin 2022-05-25 16:47:05 UTC
(note to self, --no-reload is also needed)

Comment 12 Ian Pilcher 2022-05-25 17:22:55 UTC
(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.

Comment 13 Alexander Sosedkin 2022-05-25 17:26:26 UTC
> 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.

Comment 14 Ian Pilcher 2022-05-25 17:51:20 UTC
Created attachment 1883508 [details]
Updated wrapper

Attaching updated wrapper.  Added SPDX license header (GPL 3.0 or later) and added --no-reload option to update-crypto-policies invocation.


Note You need to log in before you can comment on or make changes to this bug.