Bug 2038841
| Summary: | Provide a way to list crypto policies with a short description | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Jelle van der Waa <jvanderwaa> |
| Component: | crypto-policies | Assignee: | Alexander Sosedkin <asosedki> |
| Status: | CLOSED WONTFIX | QA Contact: | BaseOS QE Security Team <qe-baseos-security> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 9.1 | CC: | omoris |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-06-20 13:09:48 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Jelle van der Waa
2022-01-10 09:47:24 UTC
That's one interesting request. As you might have noticed, this file predates custom policies and subpolicies and needs updating.
> As custom policies are also supported policies are also supported
Truncated sentence?
One more complication I see is what's gonna be the contract of `update-crypto-policies --list`.
From the invocation alone I'd expect that it lists every discoverable policy and subpolicy; yet there are some that we'd prefer not exposing to that list of yours, such as OSPP internal-usage subpolicy or even the FIPS policy. FIPS policy isn't really something one enables directly, there's a separate `fips-mode-setup` doing more than just that (and the advised way to get to it is installing with fips=1, actually).
How fine would you be with:
* going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit and pointing to other docs for more?
* shipping these descriptions as an extra file in crypto-policies?
* ...
* extending the policy/subpolicy files format to support optional short descriptions and visibility toggles to allow generating such a list, then adding an undocumented-internal-only-but-tested --list-examples?
Asking because your request is for a command and not static descriptions, while extending the format feels like overengineering the solution.
(In reply to Alexander Sosedkin from comment #1) > That's one interesting request. As you might have noticed, this file > predates custom policies and subpolicies and needs updating. > > > As custom policies are also supported policies are also supported > > Truncated sentence? > > One more complication I see is what's gonna be the contract of > `update-crypto-policies --list`. > From the invocation alone I'd expect that it lists every discoverable policy > and subpolicy; yet there are some that we'd prefer not exposing to that list > of yours, such as OSPP internal-usage subpolicy or even the FIPS policy. > FIPS policy isn't really something one enables directly, there's a separate > `fips-mode-setup` doing more than just that (and the advised way to get to > it is installing with fips=1, actually). Yes, that's true we could maintain a blacklist I suppose in cockpit but that requires constant updating. > How fine would you be with: > * going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit > and pointing to other docs for more? That's now done in the POC https://github.com/cockpit-project/cockpit/pull/16860 > * shipping these descriptions as an extra file in crypto-policies? > * ... That's acceptable. > * extending the policy/subpolicy files format to support optional short > descriptions and visibility toggles to allow generating such a list, then > adding an undocumented-internal-only-but-tested --list-examples? That sounds like the --list option I was suggesting or am I mistaken. >> * going with static generic descriptions of LEGACY/DEFAULT/FUTURE in cockpit >> and pointing to other docs for more? > > That's now done in the POC https://github.com/cockpit-project/cockpit/pull/16860 I meant turning it even more generic and stable across releases and distros, like "LEGACY: aims at higher interoperability at the cost of an increased attack surface" "DEFAULT: aims at secure settings for current threat models" "FUTURE: aims at protecting from anticipated near-term future attacks at the expense of interoperability" and a link to the distro's equivalent of [1] instead of specifics. So, generalizing it to something that'd hold true for both RHEL-8 and Fedora 36 alike. >> adding an undocumented-internal-only-but-tested --list-examples? > > That sounds like the --list option I was suggesting or am I mistaken. I meant two differences from how I happen to read the original request: 1. Original --list sounds like it aims to somehow list either everything usable with --set or at least all the base policies discovered in the system. Hypothetical --list-examples will list just some subset of such possible values. 2. Original --list would have a public-facing --help entry and a manpage entry defining what exactly does it do (e.g., lists the base policies but not subpolicies in the order defined by etc. etc.). Hypothetical --list-examples would be for cockpit usage only, with its interface enforced only by some automated regression tests on both crypto-policies and cockpit sides. [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening |