Hi Giacomo,

On Mon, Jun 1, 2020 at 7:28 PM Brussino, Giacomo <g...@lanl.gov> wrote:
>
> Jan,
>
> Thank you very much for all the details! I really appreciate the help.
>
> I'd like to understand the bug with the DISA STIG and X Windows a bit
> more. If I use the DISA benchmark from DISA, not the upstream from Red
> Hat, and add the remediation that re-enables X Windows, then what
> happens?

The DISA STIG requires xorg-x11-server-common to be removed. Therefore
it isn't possible to install a Server with GUI or Workstation with
DISA STIG hardening. If you need GUI or X Windows, you need to remove
the rule `package_xorg-x11-server-common_removed` from the profile,
either by tailoring or manually. Obviously, the installed system won't
be fully compliant with STIG if you do that.

>
> The benchmark removes xorg-x11-server-common if installed.
> Does the remediation re-install the package?

The remediation doesn't reinstall the xorg-x11-server-common package,
it's the opposite, it tries to remove the package.

> Does it behave differently if the benchmark and tailoring file are
> merged in a single file per your suggestion?

No, it doesn't.

> When does the benchmark get applied in the kickstart?

It's in 2 phases: Before installation, it takes the benchmark and
changes the installation settings based on it, for example password
length, partitioning, packages to be installed. Then, in post phase,
it runs the whole benchmark using "oscap", basically it runs "oscap
xccdf eval --remediate" command.

> Can I re-install the package at the end of post?

I don't know, maybe others can chime in. I assume it will report that
you fail the rule, but that's expected.

>
> If the benchmark is enforced after post, then I can't work-around it,
> unless the remediation resolves it. If not, then I'll have to change
> the default boot target and fixed it after reboot.
>
> Thank you.
> Giacomo
>
>
> On Thu, 2020-05-28 at 10:31 +0200, Jan Cerny wrote:
> > Hi Giacomo,
> >
> > Let me reply in-line.
> >
> > On Wed, May 27, 2020 at 4:49 PM Brussino, Giacomo <g...@lanl.gov>
> > wrote:
> > >
> > > Thank you, Jan. Your description of the options seems to be
> > > sufficient to get things working.
> > >
> > >
> > > What I wanted to try was to get the DISA STIG benchmark from
> > > https://public.cyber.mil/stigs/supplemental-automation-content/
> > > (not the one in the scap-security-guide; not sure why Red Hat has a 
> > > different one, and what the differences are; controls might be the same 
> > > but without the ordering and classification in the DISA categories), 
> > > tailor it and then use that in a kickstart. At a minimum, I would disable 
> > > the "Disable X Windows" rule just as a prove of concept, and build a 
> > > system with a GUI.
> >
> > We serve as upstream and then DISA does some additional
> > modifications.
> >
> > Regarding the "X Windows" and STIG, this might be relevant for you:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1648162
> >
> > >
> > >
> > > As for the bug you mention, I had found the info in the open-scap-
> > > list archives (
> > > https://www.redhat.com/archives/open-scap-list/2018-October/msg00003.html
> > >  from Oct 2018), but it wasn't clear if it was fixed or not.
> >
> > It has been closed for RHEL 7 but it hasn't been fixed because a
> > workaround exists. However, the issue still persists in RHEL 8.
> >
> > > BTW, as a Red Hat customer (logged in with my account) I cannot see
> > > the bugzilla you mentioned (Bug Access Denied), but I assume the
> > > work-around is running oscap with remediation in post.
> >
> > I'm sorry for that.  As I mentioned in the previous email, the best
> > workaround is to merge the benchmark and tailoring file into a single
> > file using combine_tailoring.py script. I will copy paste the other
> > workaround options, because they aren't secret :-), but I haven't
> > tried if they work.
> >
> > The options are:
> >
> > virt-install and --initrd-inject (A)
> > putting tailoring directly into kickstart (B)
> > online RPM use (C)
> > convoluted variant of first one, using RPM (D)
> >
> > -------------
> > A:
> > 1. create xccdf tailoring utilizing scap-workbench save it as
> > my-tailoring.cfg (cfg is not a typo, and it is mandatory)
> > 2. OAA KS snippet:
> > %addon org_fedora_oscap
> >         content-type = scap-security-guide
> >         profile = <profile>
> >         tailoring-path = ../../my-tailoring.cfg
> > %end
> >
> > 3. virt-install <..> --initrd-inject my-tailoring.cfg
> >
> > Step 3 is where cfg comes to play, as xml would be ignored by virt-
> > install.
> >
> > -------------
> > B:
> > 1. same as above (this time, file name does not matter)
> > 2. encode tailoring into base64: base64 my-tailoring.xml
> > 3. OAA KS snippet:
> > %addon org_fedora_oscap
> >         content-type = scap-security-guide
> >         profile = <profile>
> >         tailoring-path = ../../my-tailoring.xml
> > %end
> > 4. insert %pre phase in the kickstart:
> > %pre
> > cat << EOF |
> > <base64 encoded tailoring file>
> > EOF
> > python -m base64 -d > my-tailoring.xml
> > %end
> >
> > -------------
> > C:
> > 1. save tailoring as RPM in SCAP Workbench
> > 2. upload it somewhere (unfortunately it is not possible to use
> > uploaded RPM) accessible with <url_path>
> > 3. OAA KS snippet:
> > %addon org_fedora_oscap
> >         content-type = rpm
> >         content-url = http://<url-path>;
> >         profile = <profile>
> >         xccdf-path = /usr/share/xml/scap/ssg-rhel7-ds/ssg-rhel7-
> > ds.xml
> >         tailoring-path = /usr/share/xml/scap/ssg-rhel7-ds/tailoring-
> > xccdf.xml
> > %end
> >
> > -------------
> > D:
> > 1. save tailoring as RPM in SCAP Workbench
> > 2. OAA KS snippet:
> > %addon org_fedora_oscap
> >         content-type = scap-security-guide
> >         profile = <profile>
> >         xccdf-path = /usr/share/xml/scap/ssg-rhel7-ds/ssg-rhel7-
> > ds.xml
> >         tailoring-path =
> > ../../usr/share/xml/scap/ssg-rhel7-ds/tailoring-xccdf.xml
> > %end
> > 3a. Bake in RPM into the image and install
> > 3b. Add %pre phase
> > %pre
> > rpm -i ssg-rhel7-ds-1-1.noarch.cfg
> > %end
> > 4b. virt-install <..> --initrd-inject <rpm with .cfg suffix>
> >
> > Hope this helps ...
> >
> > Best regards
> >
> >
> >
> >
> > >
> > >
> > > Thank you.
> > >
> > > Giacomo
> > >
> > >
> > > ________________________________
> > > From: Jan Cerny <jce...@redhat.com>
> > > Sent: Monday, May 25, 2020 04:16
> > > To: Brussino, Giacomo
> > > Cc: open-scap-list@redhat.com
> > > Subject: [EXTERNAL] Re: [Open-scap] OSCAP Anaconda Addon usage
> > > examples
> > >
> > > Hi Giacomo,
> > >
> > > Using content-type = scap-security-guide in the kickstart means
> > > that
> > > Anaconda addon uses SCAP content from the scap-security-guide RPM
> > > package in the installation media.
> > >
> > > The other options (datastream, archive, rpm) allow you to provide
> > > your
> > > own SCAP content and use it instead. The content needs to be
> > > accessible by HTTP, HTTPS or FTP during the installation and the
> > > URL
> > > needs to be provided using content-url directive in the kickstart.
> > >
> > > I prefer using the "datastream" option as it simply downloads the
> > > file
> > > from the given URL and then it just uses the downloaded file. The
> > > "archive' and "rpm" options will extract the archive or install the
> > > RPM first. But, I assume it needs to provide a relative path to the
> > > SCAP content within the archive or within the RPM using content-
> > > path
> > > directive in the kickstart, so you need to know the internal
> > > structure
> > > of the archive or RPM.
> > >
> > > Some documentation can be found in
> > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/installation_guide/index#chap-kickstart-installations
> > > in section "%addon org_fedora_oscap".
> > >
> > > Regarding the tailoring: Unfortunately, there is a bug that
> > > Anaconda
> > > addon can't process tailoring files from network sources.
> > >
> > > There is a simple workaround for the bug: You can merge the
> > > original
> > > SCAP content and tailoring file into a single file and then use
> > > this
> > > file during the installation. Get combine_tailoring.py from
> > > https://github.com/mpreisler/combine-tailoring/blob/master/combine-tailoring.py.
> > > Run this script, pass it the original datastream and the tailoring
> > > file:
> > >
> > > ./combine-tailoring.py --output ssg-rhel7-ds-combined.xml
> > > /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
> > > ssg-rhel7-ds-standard-tailoring.xml
> > >
> > > Serve the generated file ssg-rhel7-ds-combined.xml in your network
> > > and
> > > change the kickstart file.
> > >
> > > For example:
> > >
> > > %addon org_fedora_oscap
> > >        content-type = datastream
> > >        content-url =
> > > http://192.168.0.2/content/ssg-rhel7-ds-combined.xml
> > >        profile =
> > > xccdf_org.ssgproject.content_profile_standard_customized
> > > %end
> > >
> > > There are also other workarounds described in comment 14 in
> > > https://bugzilla.redhat.com/show_bug.cgi?id=1479008#c14.
> > >
> > > Best regards
> > >
> > > On Tue, May 19, 2020 at 10:12 PM Brussino, Giacomo <g...@lanl.gov>
> > > wrote:
> > > >
> > > > I have used the OSCAP Anaconda Addon with content-type scap-
> > > > security-guide and I have seen examples of usage with content-
> > > > type set to datastream. I would like to understand how to use it
> > > > with content-type archive or rpm, but I cannot locate any example
> > > > or information. It is easy to generate an RPM from scap-workbench
> > > > with a tailoring of a benchmark, and it sounds like that would be
> > > > an easy way to distribute a customized XCCDF, and wonder if that
> > > > would also make it easy to use it in a kickstart file.
> > > >
> > > >
> > > > I think the addon performs its tasks after post. Should I just
> > > > fetch and install the RPM in post and then use the content-type
> > > > datastream and use the xccdf-path to point to the XCCDF file in
> > > > /usr/share/xml/scap?
> > > >
> > > >
> > > > Thank you.
> > > >
> > > >
> > > > _______________________________________________
> > > > Open-scap-list mailing list
> > > > Open-scap-list@redhat.com
> > > > https://www.redhat.com/mailman/listinfo/open-scap-list
> > >
> > >
> > >
> > > --
> > > Jan Černý
> > > Security Technologies | Red Hat, Inc.
> > >
> >
> >
> > --
> > Jan Černý
> > Security Technologies | Red Hat, Inc.
> >

Best regards

-- 
Jan Černý
Security Technologies | Red Hat, Inc.


_______________________________________________
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Reply via email to