Hello,
On 21. 11. 21 12:34, Alex Haydock wrote:
Hi Matej,
I'm just contacting you about the OpenSCAP Anaconda Addon as I have a
few questions about the state of it currently in Fedora.
I'm a big user of ComplianceAsCode/SSG content on RHEL and various
rebuilds, and you might have seen or helped review some of my recent
contributions to the CIS content for RHEL upstream. I'm looking to see
whether it's possible to enable the same kind of automated hardening
during install for Fedora releases as the users of RHEL currently get
to enjoy.
Originally, since this is more of a Fedora question than an OAA
question, I did ask Vratislav Podzimek about the state of OAA/SSG in
Fedora as he's still listed as the active maintainer of the
oscap-anaconda-addon package for Fedora:
https://src.fedoraproject.org/rpms/oscap-anaconda-addon
The conclusion we came to was that SSG definitely doesn't ship as part
of the Fedora installer, but is still available since it can be used
post-installation or as part of SCAP Workbench etc. But he seemed
unsure why the oscap-anaconda-addon package was still being built. He
suggested I ask you about it as the upstream maintainer OAA. Unlike
SSG, I can't see any way that the OAA package could be useful if it's
not available during the installation.
So this is correct. I have been told that OAA is not part of any Fedora
installation medium, because there are no general-purpose profiles
available that would work for common folks that use Fedora.
However, the RPM is useful, for two purposes:
1. It can be abused to also install dependencies that one needs when one
would like to develop the addon and e.g. run its tests, and
2. it can be used to create an installer update that can be e.g. served
via HTTP, so the installer downloads that and includes the addon into
itself. We mainly use it with VMs for testing, but it should work for
any installation method.
I tried a few different attempts at getting the right syntax for OAA
to run as part of a Fedora kickstart, but what I notice is that when
the `/root/anaconda-ks.cfg` is written, the OAA section never gets
included. So I assume the support for that addon just isn't there in
the installer.
Yes, that's correct.
When looking, I did find an unmerged PR of yours here that makes some
changes in support for RHEL 9. I spotted that the instructions mention
running tests on Fedora, ...
Those are unit tests, when you just need Python modules.
... and suggest a syntax that should allow a Kickstarted Fedora
install to pull SCAP content from a HTTP datastream. This syntax is
one that I tried with a Fedora 35 kickstart and which still didn't
work. Is this to because the updates.img is needed before the OAA
package is actually present?
https://github.com/OpenSCAP/oscap-anaconda-addon/pull/178/files#diff-10f6b1ddae5cb39eb4cbc1a6d5230b963d8ca322b8c41e951b38ff0e1dd92342R74-R89
Yes, updates.img is how the OAA makes it into the installing system.
If OAA/SSG is completely disabled in Fedora then I understand it's a
question for the Fedora Community and FESCo whether it can be enabled
for future releases, so don't worry - I'm not trying to ask you for
help there. I'm mostly just trying to understand what you know of the
current state of things since you seem to be developing upstream and
doing it using Fedora.
We think that the answer may be a profile for home use/small office use
cases, when we may get inspired by some policies, but we remove the most
intrusive rules that don't contribute to the higher security in those cases.
Am I missing something about how to use the support for OAA in regular
Fedora releases? Why is the package there if it's not usable and needs
to be fed to the installer with an updates.img anyway? Is it just to
help with upstream development so that the package can be built to
feed the next RHEL release more easily?
Yes, RHELs often get features that appear in Fedora first, so it makes
sense to have them in the repository already. However, as of late 2021,
the Fedora (i.e. master) branch in our repository is in a very bad
shape, and we will have to think how to approach it, so we make it easy
for Anaconda folks to assist us, and we make it easier for ourselves to
develop the RHEL experience
Many thanks if you're able to help out with any of these questions,
and thanks for your work on the addon and on OpenSCAP generally!
Thank you for reaching out and for sharing that experience with us!
Best regards,
Alex
_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://listman.redhat.com/mailman/listinfo/open-scap-list
