Bug 1847454

Aargh! Lua was chosen because it (on normal rpm) does not bring any additional dependencies and allows avoiding circular dependencies on the install of the crypto-policies base package.

This is serious deficiency in rpm-ostree.

Could you please workaround this? Basically by implementing what the lua script in crypto-policies does in the coreos install itself.

BTW this was added in RHEL-8.3 package as well.

All this was done btw to properly split the crypto-policies-scripts out of the base package on demand of the minimal CoreOS image to be as small as possible and not require Python.

The circular dependency is:

any non-trivial shell script -> coreutils -> openssl -> crypto-policies

So that was the reason to use lua script.

Hi Tomas,

> Could you please workaround this? Basically by implementing what the lua script in crypto-policies does in the coreos install itself.

Yes, we can do this: https://github.com/coreos/rpm-ostree/pull/2136
Would appreciate your review there if you have a chance.

That said, I'm not sure if the Lua script is quite correct. It looks like it turns on the FIPS mode backend if the machine running the scriptlet happens to be in FIPS mode. However, this assumption does not hold for "rootfs installs" like `rpm-ostree compose tree` and e.g. `yum install --installroot`. ISTM it would make more sense if the rootfs were prepared for FIPS mode only if requested by the user. As such, wouldn't it be cleaner for crypto-policies to keep defaulting to DEFAULT? Do you have more information on the motivation for this change? Specifically referring to https://src.fedoraproject.org/rpms/crypto-policies/c/9b9c9f7378c3fd375b9a08d5283c530a51a5de34?branch=master.

(Things get blurry of course in the Anaconda case, where "user requesting FIPS mode" is indeed documented as setting `fips=1` in the installer boot, but the automatic forwarding to the installed system worked before this change, right?)

Yeah, see also http://post-office.corp.redhat.com/archives/coreos-devel/2020-June/msg00082.html
and https://bugzilla.redhat.com/show_bug.cgi?id=1800697

If this is related to that, I think the FIPS handling needs to be done in the installer and not the crypto-policies RPM package.

> Status: CLOSED → NEW

Heh, I was going to reopen this, but didn't want to mix up the two issues. I guess I did that though by commenting here instead of opening a new bug.
Anyway, retitling this one to be more precise now.

(That said, if the path forward is to revert https://src.fedoraproject.org/rpms/crypto-policies/c/9b9c9f7378c3fd375b9a08d5283c530a51a5de34?branch=master to drop the lua scriptlet, that clearly helps us too in the short-term.)

I agree with Alex. This script is meant to be a stop-gap measure in case the installer does not do anything and the system being installed is in the FIPS mode.

Dropping the lua script is not the way to go.

And the https://src.fedoraproject.org/rpms/crypto-policies/c/9b9c9f7378c3fd375b9a08d5283c530a51a5de34?branch=master does not solve just the DEFAULT vs. FIPS policy on install but also the issue with .rpmnew files being created on upgrades of crypto-policies.

> could you please elaborate what exactly breaks by setting the symlinks to FIPS crypto-policy in the target system?

In general, we don't want to ship our images/OSTrees with FIPS enabled by default. But more importantly, we want to isolate properties of the composed rootfs from its build environment. And this is a major leak of that. (To be fair, I'm sure there are other more minor leaks that do happen, though I'm not aware of any offhand).

> What are those interesting deployments where the installer machines 'happen' to be in FIPS mode, but the resulting images are not supposed to be in FIPS?

This affects rpm-ostree, which is used to compose RHCOS, FCOS, Fedora IoT, and Fedora Silverblue. To expand, rpm-ostree performs composes on the server side, e.g. in the Fedora or CentOS CI or Red Hat infrastructure. Whether that server we happen to be scheduled on for doing the compose is in FIPS mode or not should have no impact on whether FIPS mode is turned on in the composed image/rootfs. That should be customizable by the user at provisioning time.

In practice, for the spins which use coreos-assembler (RHCOS and FCOS for now), we're isolated from that by the fact that we run the compose via supermin. Though that approach was meant as a way to run privileged operations, not really as an isolation mechanism (and coreos-assembler supports running rpm-ostree directly if it has enough privileges). Also, at least IoT and Silverblue today aren't using coreos-assembler.

>  Are those, maybe, exotic enough to be outright unsupported, or to warrant mocking the FIPS kernel flag to be zero through the builder environment?

Sure, we could do this (or simpler would be to postprocess the rootfs so that it's always in DEFAULT mode), but very often something like this is a symptom of upstream bits needing tweaks. :) We try to keep these kinds of downstream workarounds in rpm-ostree to a minimum.

> Dropping the lua script is not the way to go.

To be clear, I'm fine with lua in the end if that's what we land on. Right now, we're discussing upstream on ways to support it. The base issue though is that this script is misbehaving in the context of rootfs composes. Another obvious use case is creating containers, see e.g. https://opensource.com/article/19/3/tips-tricks-rootless-buildah, which uses `dnf install -y --installroot`.

Another good example of this is say when we go to build a Docker/OCI container base image like registry.fedoraproject.org/fedora:32 or RHEL UBI.  In this scenario we don't want to enable FIPS in the generated container image if the host happens to have FIPS.

And really more generally, I think we should not have sophistication in RPM scripts - at the layer of package installation it should mostly just be unpacking and updating caches.

Instead, things like "enable FIPS" should be handled by higher level tooling (whether that's Kickstart, Ignition, Ansible - and all of those might wrap a script to do it).

(Oh sorry Jonathan also mentioned containers at the end, I missed that.)

I can only repeat that the lua script is a stop-gap measure and if the builders want always the DEFAULT policy in the images they either should not run on FIPS enabled host, they should just set the DEFAULT policy explicitly after the image is built, or they should mask the /proc/sys/crypto/fips_enabled flag.

And if there was a simple way how to detect that we are building an image from the lua script I could add that condition to force the DEFAULT policy.

The thing is I could not really imagine a scenario where the host is FIPS enabled and the admin/user building an image would like to build a non-FIPS image. It would be even the best way how to achieve full FIPS compliance across all the use-cases.

> The thing is I could not really imagine a scenario where the host is FIPS enabled and the admin/user building an image would like to build a non-FIPS image. It would be even the best way how to achieve full FIPS compliance across all the use-cases.

The RHEL buildsystems are that scenario.  We make a generic operating system that can be configured downstream.  Our builds should be independent of the host.
If you don't believe me, feel free to ask RCM, I am pretty sure they'll agree.

This is a distinct thing from *downstream* users/customers making their own images which I think you're imagining (this case is more like RHEL Image Builder).

Which is in turn distinct in many ways from something like Anaconda/Ignition where things end up being enabled by configuration.

(In reply to Colin Walters from comment #15)
> > The thing is I could not really imagine a scenario where the host is FIPS enabled and the admin/user building an image would like to build a non-FIPS image. It would be even the best way how to achieve full FIPS compliance across all the use-cases.
> 
> The RHEL buildsystems are that scenario.  We make a generic operating system
> that can be configured downstream.  Our builds should be independent of the
> host.
> If you don't believe me, feel free to ask RCM, I am pretty sure they'll
> agree.


No, this is not the case. The RHEL buildsystems are not running as FIPS enabled and they never should. Much more would break than this thing if they ran as FIPS enabled.

The lua script is doing the right thing.  If a builder is running FIPS mode, I'd expect whatever it builds to also follow that policy.  RHEL/UBI Containers follow this today by the `/etc/system-fips -> /run/secrets/system-fips` symlink which at least openssl honors.  (not sure about the other crypto stacks)

If expect any "distro" builders to be running with a DEFAULT policy, not FIPS.  Generally, I agree that rpm-ostree should fix the lua script execution.

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 33 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.