RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1829669 - Document how to install an arbitrary pre-generated policy in RHEL 8.2 and above
Summary: Document how to install an arbitrary pre-generated policy in RHEL 8.2 and above
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: crypto-policies
Version: 8.2
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: rc
: 8.3
Assignee: Tomas Mraz
QA Contact: Ondrej Moriš
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-04-30 03:09 UTC by James Ralston
Modified: 2024-03-25 15:52 UTC (History)
3 users (show)

Fixed In Version: crypto-policies-20200527-1.git0a29b28.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:58:27 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2020:4536 0 None None None 2020-11-04 01:58:40 UTC

Description James Ralston 2020-04-30 03:09:18 UTC
Description of problem:

In the crypto-policies package before RHEL 8.2, additional policies were added to the system by creating a custom policy directory and populating all of the back-end files in that directory.

We leveraged that capability to roll our own custom policy for our RHEL8 hosts. It worked well.

But starting with RHEL 8.2, the mechanism to create custom policies has changed. Instead of creating the required back-end files, one creates a POLICY.pol file, and (optionally) various MODIFICATIONS.pmod files. Rather than focusing on specific applications, the *.pol policy language tends to describe the overall state of the system in terms of permitted ciphers, hashes, key lengths, et. al.

Unfortunately, this change has broken our ability to install our own custom policy by pre-generating the necessary back-end files.

Yes, we see the value of the simplistic *.pol policy language for novice administrators. But for advanced configurations, precise and application-specific tailoring is necessary, and the current policy language is wholly inadequate for this task. (This is particularly true in cases where compliance with various standards is required, and compliance with said standards is audited.)

Please bring back the ability to specify an exact back-end policy structure.

Specifically, if I run:

$ update-crypto-policies --set MYPOLICY

…if none of these policy files exists:

/etc/crypto-policies/policies/MYPOLICY.pol
/usr/share/crypto-policies/policies/MYPOLICY.pol

…but a pre-generated back-end directory structure exists:

/usr/share/crypto-policies/MYPOLICY/
/usr/share/crypto-policies/MYPOLICY/bind.txt
/usr/share/crypto-policies/MYPOLICY/gnutls.txt
/usr/share/crypto-policies/MYPOLICY/java.txt
/usr/share/crypto-policies/MYPOLICY/krb5.txt
/usr/share/crypto-policies/MYPOLICY/libreswan.txt
/usr/share/crypto-policies/MYPOLICY/libssh.txt
/usr/share/crypto-policies/MYPOLICY/nss.txt
/usr/share/crypto-policies/MYPOLICY/opensshserver.txt
/usr/share/crypto-policies/MYPOLICY/openssh.txt
/usr/share/crypto-policies/MYPOLICY/opensslcnf.txt
/usr/share/crypto-policies/MYPOLICY/openssl.txt

…then update-crypto-policies should simply install the contents of the /usr/share/crypto-policies/MYPOLICY directory to /etc/crypto-policies/back-ends directory and assert that the MYPOLICY policy is in effect.

Without functionality like this, we will have no choice but to simply stomp the contents of the /etc/crypto-policies/back-ends directory with the specific back-end policy we need, because there is no way to express the nuances of the application-specific policies we need using the *.pol language.

We don't want to do this. We recognize that attempting to centralize Linux cryptographic configuration is a laudable goal, and we are grateful that Red Hat has undertaken this (challenging!) endeavor. We also see the value in attempting to simply the cryptographic configuration for novice administrators. But this simplification cannot come at the cost of preventing non-novice administrators from exerting exact control over the various policies for the various back-ends.

Version-Release number of selected component (if applicable):

20191128-2.git23e1bf1.el8

Comment 1 Tomas Mraz 2020-04-30 07:19:25 UTC
This should work fine. It should be sufficient to provide an empty /etc/crypto-policies/policies/MYPOLICY.pol and the hardcoded back-ends from /usr/share/crypto-policies/MYPOLICY/*.txt should still be used and symlinked into the /etc/crypto-policies/back-ends.

If that does not work, then it would be a bug.

Comment 2 James Ralston 2020-05-05 04:33:19 UTC
I can confirm that providing an empty MYPOLICY.pol file does indeed cause the pre-generated back-ends from /usr/share/crypto-policies/MYPOLICY to be symlinked into /etc/crypto-policies/back-ends.

Could this logic be documented in crypto-policies(7), please? It is not currently documented, and it is not necessarily obvious, either.

Thanks!

Comment 10 errata-xmlrpc 2020-11-04 01:58:27 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (crypto-policies bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4536


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