Hello everyone, we have currently stumbled upon situation, where Ansible remediation snippet can either fix 3 different rules at once, or be very convoluted. Technical details aside [1] - what is your view of such approach?
* Is it ok when remediation does change more than the rule that triggered it checks? * Do you prefer to have no remediation at all, to the remediation that does too much? * Does answer to the questions above change between (--remediate) which is applied automatically, and bash roles or ansible playbooks, where you can check insides of the scripts and alter them before application?
Thanks! Marek
[1] https://github.com/ComplianceAsCode/content/pull/3723#issuecomment-462747526
In my opinion, the system should be safe, consistent, and correct regardless of the number of times it is remediated.
If that requires changing more than just what the checks cover, that is appropriate but should be documented as such.
Trevor
On Tue, Feb 12, 2019 at 11:50 AM Marek Haicman mhaicman@redhat.com wrote:
Hello everyone, we have currently stumbled upon situation, where Ansible remediation snippet can either fix 3 different rules at once, or be very convoluted. Technical details aside [1] - what is your view of such approach?
- Is it ok when remediation does change more than the rule that
triggered it checks?
- Do you prefer to have no remediation at all, to the remediation that
does too much?
- Does answer to the questions above change between (--remediate) which
is applied automatically, and bash roles or ansible playbooks, where you can check insides of the scripts and alter them before application?
Thanks! Marek
[1]
https://github.com/ComplianceAsCode/content/pull/3723#issuecomment-462747526 _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
On 2/12/19 11:49 AM, Marek Haicman wrote:
Hello everyone, we have currently stumbled upon situation, where Ansible remediation snippet can either fix 3 different rules at once, or be very convoluted. Technical details aside [1] - what is your view of such approach?
- Is it ok when remediation does change more than the rule that
triggered it checks?
Current methodology ensures higher-level technologies can compose custom security baselines (incl SCAP and remediation). Kind of like what SCAP Workbench does.
If we can't track one configuration item to specific XCCDF/OVAL/remediation, all that falls apart.
- Do you prefer to have no remediation at all, to the remediation that
does too much?
Would have to understand what "too much" means. Very surprised Ansible wouldn't be able to remediate single configuration checks. Worst case use the shell capabilities and run whatever the bash snippet would be.
- Does answer to the questions above change between (--remediate)
which is applied automatically, and bash roles or ansible playbooks, where you can check insides of the scripts and alter them before application?
If running --remediate, multiple CCEs are somehow grouped into a single ansible action, how do I troubleshoot that?
Because they are separate rules, they should be separate remediations. Of course if the upstream faillock BZ [1] was prioritized and dealt with sooner, we probably wouldn't necessarily be having this discussion.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1537242
On Tue, Feb 12, 2019 at 10:45 AM Shawn Wells shawn@redhat.com wrote:
On 2/12/19 11:49 AM, Marek Haicman wrote:
Hello everyone, we have currently stumbled upon situation, where Ansible remediation snippet can either fix 3 different rules at once, or be very convoluted. Technical details aside [1] - what is your view of such approach?
- Is it ok when remediation does change more than the rule that
triggered it checks?
Current methodology ensures higher-level technologies can compose custom security baselines (incl SCAP and remediation). Kind of like what SCAP Workbench does.
If we can't track one configuration item to specific XCCDF/OVAL/remediation, all that falls apart.
- Do you prefer to have no remediation at all, to the remediation that
does too much?
Would have to understand what "too much" means. Very surprised Ansible wouldn't be able to remediate single configuration checks. Worst case use the shell capabilities and run whatever the bash snippet would be.
- Does answer to the questions above change between (--remediate)
which is applied automatically, and bash roles or ansible playbooks, where you can check insides of the scripts and alter them before application?
If running --remediate, multiple CCEs are somehow grouped into a single ansible action, how do I troubleshoot that? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
PAM issue is one thing, but the discussion can help make sure we are on the same page, and have same understanding what is expected :)
On 2/12/19 6:47 PM, Gabe Alford wrote:
Because they are separate rules, they should be separate remediations. Of course if the upstream faillock BZ [1] was prioritized and dealt with sooner, we probably wouldn't necessarily be having this discussion.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1537242
On Tue, Feb 12, 2019 at 10:45 AM Shawn Wells <shawn@redhat.com mailto:shawn@redhat.com> wrote:
On 2/12/19 11:49 AM, Marek Haicman wrote: > Hello everyone, > we have currently stumbled upon situation, where Ansible remediation > snippet can either fix 3 different rules at once, or be very > convoluted. Technical details aside [1] - what is your view of such > approach? > > * Is it ok when remediation does change more than the rule that > triggered it checks? Current methodology ensures higher-level technologies can compose custom security baselines (incl SCAP and remediation). Kind of like what SCAP Workbench does. If we can't track one configuration item to specific XCCDF/OVAL/remediation, all that falls apart. > * Do you prefer to have no remediation at all, to the remediation that > does too much? Would have to understand what "too much" means. Very surprised Ansible wouldn't be able to remediate single configuration checks. Worst case use the shell capabilities and run whatever the bash snippet would be. > * Does answer to the questions above change between (--remediate) > which is applied automatically, and bash roles or ansible playbooks, > where you can check insides of the scripts and alter them before > application? If running --remediate, multiple CCEs are somehow grouped into a single ansible action, how do I troubleshoot that? _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org <mailto:scap-security-guide@lists.fedorahosted.org> To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org <mailto:scap-security-guide-leave@lists.fedorahosted.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...
scap-security-guide@lists.fedorahosted.org
-
Gabe Alford -
Marek Haicman -
Shawn Wells -
Trevor Vaughan