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

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

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]
Updated wrapper

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

Thank you!

Published at https://gitlab.com/redhat-crypto/crypto-policies-extras
Built in COPR at https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras

*** Bug 2196856 has been marked as a duplicate of this bug. ***

As RHEL-9 matures, the chance of landing a proper solution in RHEL-9 timeframe gets slimmer. =(

Can we fix this upstream or for RHEL 10?  I've had several people send me
rewardzone points for working out the magic incantation for this, indicating
it's a common problem.

I'd like to explore that, yes. So far, the most user-friendly solution seems to be controlling policy with environment variables, but for that we'd need to
1. introduce extra config-picking logic into each of crypto-policies back-ends
2. solve pre-generating and updating custom policies
3. iron out all edge cases to at least fail close
which would be quite an undertaking.

On the other hand, the wrapper is cool, is written already and if somebody teaches me how to easily wrap systemd services with it, maybe the wrapper would be the way.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.