obs-build
obs-build copied to clipboard
openSUSE
Derived container builds do not take packages in the base image into account
There are multiple packages providing openSUSE-release: openSUSE-release-{mini,dvd,ftp,...}.
The base container image explicitly installs openSUSE-release-ftp to resolve the have choice error, but it pops up again when building derived images.
we are seeing the same issue also on IBS (obviously) when building on SLE repository, since it contains all the available -release packages for all products (SLES / SLED / HPC / etc).
This is really becoming a problem now that patterns-base-fips with dependencies such as (libcryptsetup12-hmac if libcryptsetup12) is part of the base containers. OBS doesn't see that the pattern is installed by the base and thus doesn't add the -hmac package into the buildroot, but zypper rightfully complains about the broken dependency.
the derived containers could just "zypper in patterns-base-fips" again if they want to be fips enabled.
(or we undo the -hmac split which I'm not actually sure is worth it as there is no secret in there :( )
(or we undo the -hmac split which I'm not actually sure is worth it as there is no secret in there :( )
I never understood that either.
the hmac split is for marking the "FIPS Module" complete or incomplete, which changes the behaviour of the module (either need to do selftests on startup or not). this is not a secrecy thing, but a definition thing.
@msmeissn well, unnamed other distros that have FIPS-140-2 simply package the hmacs in the library package, and determine complete or incomplete state based on the fips=X setting in /proc/cmdline. It's not entirely clear to me what we're fixing with this setup which is essentially a tri-state, and the third state actually causes it to immediately assert on start.
Canonical uses separate hmac packages, similar to what we do, completeness is determined when both are installed.
Red Hat uses its crypto policy framework to complete the FIPS modules. Quick look seems that it writes a single file /etc/system-fips to declare (all) the module as complete at once.
Enabling fips mode operation is done with fips=1 kernel bootline also for Red Hat.
We cannot change our way of doing this for 15-sp3 and older as the security policies have been issued already.
For 15-sp4 we can change it for the FIPS 140-3 certification which is currently in development.
Canonical uses separate hmac packages, similar to what we do, completeness is determined when both are installed.
i.e. the libraries/programs behave differently if the .hmac file is present, even without fips=1?
FIPS uses a 3 state model:
- module is not complete .... the module cannot operate in FIPS mode, no self tests are done
- module is complete (not not in FIPS Mode) ... the module runs self-tests and integrity checks, but does not operate in FIPS Mode
- module is complete AND operates in FIPS mode ... self-tests + integrity checks are done, and module enforecs FIPS restrictions and methods
The "completeness" is something the module can detect during startup and is documented... we chose the presence of .hmac files used for integrity checking also as completeness for our fips libraries. RH apparently uses the presence of the /etc/system-fips file for completeness declaration.
(as background: think in terms of hardware ... "module" with open covers ... module glued together and FIPS switch in OFF position ... module glued together and the FIPS switch in ON position.
Can't I get a opensuse/leap:15.2 as a base image where FIPS is enabled? Thanks
Can't I get a opensuse/leap:15.2 as a base image where FIPS is enabled? Thanks
That's a bit off-topic here. 15.2 is EOL, 15.4 has FIPS included. You can run zypper install pattern:fips in the 15.3 container yourself to install the necessary packages.