Bug 1804193
Summary: | Podman support for FIPS Mode requires a bind mount inside the container [container-tools-rhel8-rhel-8.3.0/podman] | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Jindrich Novy <jnovy> | ||||||
Component: | podman | Assignee: | Tom Sweeney <tsweeney> | ||||||
Status: | CLOSED ERRATA | QA Contact: | atomic-bugs <atomic-bugs> | ||||||
Severity: | unspecified | Docs Contact: | Gabriela Nečasová <gnecasov> | ||||||
Priority: | unspecified | ||||||||
Version: | 8.3 | CC: | bbaude, ddarrah, dornelas, dwalsh, gnecasov, imcleod, jligon, jnovy, lfriedma, lmanasko, lmiksik, lsm5, mheon, pasik, ssorce, tmraz, tsweeney, weshen | ||||||
Target Milestone: | rc | ||||||||
Target Release: | --- | ||||||||
Hardware: | Unspecified | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | podman-1.9.3 and newer | Doc Type: | Bug Fix | ||||||
Doc Text: |
.Notes on FIPS support with Podman
The Federal Information Processing Standard (FIPS) requires certified modules to be used. Previously, Podman correctly installed certified modules in containers by enabling the proper flags at startup. However, in this release, Podman does not properly set up the additional application helpers normally provided by the system in the form of the FIPS system-wide crypto-policy. Although setting the system-wide crypto-policy is not required by the certified modules it does improve the ability of applications to use crypto modules in compliant ways.
To work around this problem, change your container to run the `update-crypto-policies --set FIPS` command before any other application code was executed. The `update-crypto-policies --set FIPS` command is no longer required with this fix.
|
Story Points: | --- | ||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2020-11-04 03:05:10 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 1784950, 1804543 | ||||||||
Attachments: |
|
Description
Jindrich Novy
2020-02-18 12:32:48 UTC
Yes I agree, this is not fixing the issue fully in RHEL8. We will not be getting this fixed quickly, but the question is how much is broken. Will this prevent a container platform from getting fully certified as FIPS 140. IE Do we have the same level of support as we do for a RHEL7 container and is this enough? Ok we did some experimenting on fips mode. I believe adding echo /etc/crypto-policies/back-ends:/etc/crypto-policies/back-ends >> /usr/share/containers/mounts.conf Should fix the issue. The fips-mode-check tool will NOT work to check if the container is in fips mode, since it requires dracut and an initrd to be available inside of the container, so we don't have a decent tool to check if everything is setup correctly. Don't know of other tools. Per Dan's comment #12, we've added: # cat /usr/share/containers/mounts.conf /usr/share/rhel/secrets:/run/secrets /etc1/crypto-policies/back-ends:/etc/crypto-policies/back-ends And then ran: # podman run -it --rm --privileged ubi8 [root@a5fd343a83ea /]# [root@a5fd343a83ea /]# /usr/bin/fips-mode-setup --check /usr/bin/fips-mode-setup: line 66: lsinitrd: command not found Installation of FIPS modules is not completed. FIPS mode is enabled. Inconsistent state detected. [root@a5fd343a83ea /]# ls /usr/bin/lsinitrd ls: cannot access '/usr/bin/lsinitrd': No such file or directory [root@a5fd343a83ea /]# yum install dracut Updating Subscription Management repositories. Unable to read consumer identity Subscription Manager is operating in container mode. ... Installed: dracut-049-27.git20190906.el8_1.1.x86_64 kbd-2.0.4-8.el8.x86_64 hardlink-1:1.3-6.el8.x86_64 pigz-2.4-2.el8.x86_64 kpartx-0.8.0-5.el8.x86_64 kbd-legacy-2.0.4-8.el8.noarch procps-ng-3.3.15-1.el8.x86_64 systemd-udev-239-18.el8_1.4.x86_64 xz-5.2.4-3.el8.x86_64 libkcapi-hmaccalc-1.1.1-16_1.el8.x86_64 kmod-25-13.el8.x86_64 cpio-2.12-8.el8.x86_64 kbd-misc-2.0.4-8.el8.noarch libkcapi-1.1.1-16_1.el8.x86_64 Complete! [root@a5fd343a83ea /]# /usr/bin/fips-mode-setup --check No <initramfs file> specified and the default image '/boot/initramfs-4.18.0-147.el8.x86_64.img' cannot be accessed! Usage: lsinitrd [options] [<initramfs file> [<filename> [<filename> [...] ]]] Usage: lsinitrd [options] -k <kernel version> -h, --help print a help message and exit. -s, --size sort the contents of the initramfs by size. -m, --mod list modules. -f, --file <filename> print the contents of <filename>. --unpack unpack the initramfs, instead of displaying the contents. If optional filenames are given, will only unpack specified files, else the whole image will be unpacked. Won't unpack anything from early cpio part. --unpackearly unpack the early microcode part of the initramfs. Same as --unpack, but only unpack files from early cpio part. -v, --verbose unpack verbosely. -k, --kver <kernel version> inspect the initramfs of <kernel version>. Installation of FIPS modules is not completed. FIPS mode is enabled. Inconsistent state detected. If there are adjustments or additions I could make to the above, please let me know. If this is mounting the host's directory in the container what will happen is that the container will blow up if the host and the container used different version of RHEL for their packages. The working mechanism is described here: https://projects.engineering.redhat.com/browse/CRYPTO-535 The description field contains the necessary steps. To test if fips mode is properly activated you can write a small program that tries to use EVP_md5() from openssl to make a digest, it will be blocked in FIPS mode. Actually a smal lgo program that tries to generate a md5 sum should also fail, and that will also test that the golang tooling properly works in fips mode. https://github.com/containers/buildah/pull/2246 Should fix the issue. The problem is the documentation for this is WRONG. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening The following # mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends Should be: # mount --bind /usr/share/crypto-policies/FIPS /etc/crypto-policies/back-ends We coded up the original mount command and no one ever verified it was working until now. NO! This is simply wrong! The documentation is right and the mount --bind /usr/share/crypto-policies/back-ends/FIPS /etc/crypto-policies/back-ends is correct! Dan, you're probably looking at some old version of crypto-policies package. Possibly from RHEL-8.1! Ok so this means that we need to test against a UBI Image build on RHEL8.2 packages. So this needs to go back to QE, Edward could you retest with an updated UBI Image. Created attachment 1675296 [details]
strace log of running the container with fips mode enabled.
Created attachment 1675391 [details]
strace log of running the container with fips mode enabled.
Thank you. So from the strace this is the problem: 11157 newfstatat(AT_FDCWD, "/var/run/containers/storage/overlay-containers/954ba027da6523bb9908a23db0885961063eb4ede35ea38df10c12a72b1e9275/userdata/usr/share/crypto-policies/back-ends/FIPS", 0xc000418ed8, 0) = -1 ENOENT (No such file or directory) The ubi8:8.2-203 image should contain the /usr/share/crypto-policies/back-ends/FIPS (as verified by the buildah working with this image) so there must be something else in play here. This should be fixed, Tomas please confirm. Which version of podman are we talking here about? When I run: podman run -it --rm -v /etc/system-fips:/etc/system-fips ubi8 It will still not bind-mount the /usr/share/crypto-policies/back-ends/FIPS and I still see just the symlinks to DEFAULT. [root@7f4578701937 /]# ls -l /etc/crypto-policies/back-ends/ total 0 lrwxrwxrwx. 1 root root 43 Apr 23 05:14 bind.config -> /usr/share/crypto-policies/DEFAULT/bind.txt lrwxrwxrwx. 1 root root 45 Apr 23 05:14 gnutls.config -> /usr/share/crypto-policies/DEFAULT/gnutls.txt lrwxrwxrwx. 1 root root 43 Apr 23 05:14 java.config -> /usr/share/crypto-policies/DEFAULT/java.txt lrwxrwxrwx. 1 root root 43 Apr 23 05:14 krb5.config -> /usr/share/crypto-policies/DEFAULT/krb5.txt lrwxrwxrwx. 1 root root 48 Apr 23 05:14 libreswan.config -> /usr/share/crypto-policies/DEFAULT/libreswan.txt lrwxrwxrwx. 1 root root 45 Apr 23 05:14 libssh.config -> /usr/share/crypto-policies/DEFAULT/libssh.txt lrwxrwxrwx. 1 root root 42 Apr 23 05:14 nss.config -> /usr/share/crypto-policies/DEFAULT/nss.txt lrwxrwxrwx. 1 root root 46 Apr 23 05:14 openssh.config -> /usr/share/crypto-policies/DEFAULT/openssh.txt lrwxrwxrwx. 1 root root 52 Apr 23 05:14 opensshserver.config -> /usr/share/crypto-policies/DEFAULT/opensshserver.txt lrwxrwxrwx. 1 root root 46 Apr 23 05:14 openssl.config -> /usr/share/crypto-policies/DEFAULT/openssl.txt lrwxrwxrwx. 1 root root 49 Apr 23 05:14 opensslcnf.config -> /usr/share/crypto-policies/DEFAULT/opensslcnf.txt This is with podman-1.9.2-1.module+el8.2.1+6626+598993b4.x86_64 And this is in the strace: 6289 newfstatat(AT_FDCWD, "/var/run/containers/storage/overlay-containers/9739d7e09ee94eefc73b94a8b524318c8e76260e5fb5c6e06f9a02da257ffd9a/userdata/usr/share/crypto-policies/back-ends/FIPS", 0xc000444378, 0) = -1 ENOENT (No such file or directory) So that does not seem to be fixed at least with the version above. You should not need to do the `-v /etc/system-fips:/etc/system-fips`, this should happen automatically. And /etc/system-fips -> /run/securet/system-fips. Podman should complete the link if the system is in Fips mode. If podman is looking for the /usr/share/crypto-policies/back-ends/FIPS in userdata then this would be a bug. It should be looking for that content in the image. Jindrich, heads up. New PR to further address this issue: https://github.com/containers/libpod/pull/6281 Tom, you should add the caveat of crypto policies not being enforced correctly in 8.2 based products as a release note or similar, but the libraries themselves do not rely on crypto-policicies for FIPS validation so even w/o the correct policy the claim Openshift makes of using FIPS validated cryptography is fulfilled. HTH, Simo. I agree that we can claim FIPS compliance, and the crypto policies will be fixed in podman-1.9.3 which should be in RHEL8.2.1 in about 10 weeks. Moving this to 8.3.0 as it's already too late for 8.2.1 unless podman-1.9.3 is released before 29th May. Simo if you could create a release note on your caveat and add it to the Doc Text of this BZ, I'd very much appreciate that. Gabriela asked for help on reviewing the release notes text. For tracing purposes I am setting the text I suggested her on this bug so that others can also see an comment if they like. Since we have this in podman 2.0 I am moving to Post. 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 (Moderate: container-tools:rhel8 security, 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/RHSA-2020:4694 |