Hi Chuck,
it's definitely not like we are moving away from bash remediations
towards Ansible. As the remediation during scan is still bash-only, bash
is still important part of SSG. It's true that in upstream SSG we tried
to get Ansible to parity with bash, and it's even true that in some
cases Ansible remediation is easier to make, thus is implemented first.
Basically - it's more about resources available, and not much about our
agenda. And with Ansible remediations on par with bash, we should be
able to fix both.
Regards,
Marek
On 12/12/2017 06:23 PM, Chuck Atkins wrote:
I've got a small air-gapped network of only 2 machines that I'm setting
up. As such, centralized management and deployment configurations for
larger or even moderate sized networks are really way overkill. In the
past with RHEL6 I could easily do it all manually, i.e. install, apply
updates, run the STIG workstation profile with --remediate, and that
would get me 95% of the way there. The remainder was usually just
manually editing a few config files and that was it. So now that I'm
trying to use the OSPP profile with RHEL7 I'm finding it incredibly
frustrating how much just doesn't work out of the box now that much of
the remediation content is in ansible only. The mass of GDM
configuration parameters can't even be set by "remediate" anymore
because so much of the fix content is now ansible only.
Given the mix of ansible and bash content, what's the right now to use
this now? Should I evaluate once and generate the ansible remediation
playbook, apply it, then evaluate again with --remediate to apply the
remaining bash fixes? I've read a lot of "you can do these things with
the ansible content now" but nothing that's really along the lines of
how to actually generate and use it. Earlier versions of the SSG were
very easy to get a system up and running and almost in complete
compliance with the government profiles, right out of the box with a
single command. The path to do this seems to have greatly increased in
complexity, or at the very least, is no longer documented how to do so
easily.
I certainly appreciate the extra capability and content being added into
the SSG, so I don't want this to just be a rant on diminishing that. I
do feel, however, that it has come at the cost of usability.
----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
On Tue, Dec 12, 2017 at 11:52 AM, Watson Yuuma Sato <[email protected]
<mailto:[email protected]>> wrote:
Hello Chuck,
On 12/12/17 17:35, Chuck Atkins wrote:
There seems to be a mix of ansible and bash for fix-up scripts, in
that some rules only have bash fixes, others only have ansible
fixes, while most have both, and a few still have none. When
applying remediation during a scan, which ones get used?
When doing on-line remediation, i.e. by option "--remediate", the
bash fixes are applied.
Is there a way to specify?
Unfortunately no, the default is to use bash, and there is no way to
change it.
If I have ansible installed, will the ansible fixes automatically
get used? If the ansible ones are being used? Do the bash-only
fixes get run as well? What about rules that have both?
Ansible remediations are not applied automatically, oscap can't
consume ansible fixes. They should be used by ansible to fix the
machine.
Oscap can only generate a script fix based on one kind of
remediation, it doesn't know how to use mainly one type of fix, and
fill the gaps with other types of remediation, but this feature
sounds interesting and useful.
Thanks
----------
Chuck Atkins
Staff R&D Engineer, Scientific Computing
Kitware, Inc.
_______________________________________________
scap-security-guide mailing list
[email protected]
<mailto:[email protected]>
To unsubscribe send an email
[email protected]
<mailto:[email protected]>
--
Watson Sato
Security Technologies | Red Hat, Inc
_______________________________________________
scap-security-guide mailing list --
[email protected]
<mailto:[email protected]>
To unsubscribe send an email to
[email protected]
<mailto:[email protected]>
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
scap-security-guide mailing list -- [email protected]
To unsubscribe send an email to [email protected]
