Are they modules default in Puppet or are they custom or downloaded separately? If they are default in a standard Puppet install, it should be no problem as that is what we do with Ansible tasks.

On Mon, Feb 17, 2020 at 2:58 PM Trevor Vaughan tvaughan@onyxpoint.com wrote:

I was looking to update the Puppet remediations to be in-line with the others since I have the material.

The issue is that some of them are best served by using a Puppet module instead of repeating the code in the section itself and have a data and code component.

In many cases, you could add the remediation inline but it's going to be inferior to using a more robust module and leads to unmaintainable code duplication.

Thanks,

Trevor

On Thu, Feb 13, 2020 at 5:03 AM Matěj Týč matyc@redhat.com wrote:

...

A remediation snippet is supposed to be self-contained. We have a legacy functionality for shared bash functions for bash remediations, but all new remediation families should jinja macros in cases when remediation code is shared across multiple rules, and you are thinking about reducing remediation code duplication.

Check out e.g. https://github.com/ComplianceAsCode/content/blob/master/docs/manual/develope... to learn more about writing bash remediations. On 12. 02. 20 23:31, Trevor Vaughan wrote:

I was looking at updating some of these but do they have to be 100% self contained?

Obviously, some items are quite complex and there is code to do what is required, but I'm not sure how detailed we want to go.

Thanks,

Trevor

-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

---

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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...

-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788

-- This account not approved for unencrypted proprietary information -- _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...

The modules are downloaded separately.

Fundamentally, it would be something like the following:

# Command $ puppet module install voxpupuli-selinux

# Hiera Data

selinux::enable: true

# Puppet Code include selinux

Alternatively, something like:

# Command $ puppet module install voxpupuli-selinux

# Puppet Code class { 'selinux': enable => true }

What I'm trying to figure out is whether or not this type of thing is OK as a remediation.

The first form is preferred due to complexities.

Thanks,

Trevor

On Mon, Feb 17, 2020 at 5:20 PM Shawn Wells shawn@redhat.com wrote:

On 2/17/20 5:06 PM, Gabe Alford wrote:

...

Are they modules default in Puppet or are they custom or downloaded separately? If they are default in a standard Puppet install, it should be no problem as that is what we do with Ansible tasks.

And if they're custom, there are always the jinja templates. For example:

https://github.com/ComplianceAsCode/content/blob/master/shared/macros-ansibl...

https://github.com/ComplianceAsCode/content/blob/master/shared/macros-bash.j... _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...

The format would make sense to general Puppet users.

Basically, if I say `puppet module install voxpupuli-selinux`, I know that this means that I need to install the "selinux" module by the "voxpupuli" author regardless of how I do it. It provides enough information for a Puppet user to know what to do.

Technically, we could certainly include a Puppetfile and that would work quite well. I'll freely admit that most of my patches will come with the SIMP stack because it was specifically designed to meet these requirements.

That's part of the question, if I can do something with three different modules, which one do I choose? Also, frankly, does it matter as long as there's someone that provides care and feeding to the stack (the one requirement that I would place is that the referenced materials be FOSS unless there is no other option)?

If multiple rules attempt to download the same module, nothing bad will happen, the tool simply notes that the module is installed and continues on.

Where this gets slightly hairy is in running multiple individual rules. Take, for instance, the audit rules. It would be best if they were all tackled at the same time and a new puppet user may not know that they need to make their data layer additive instead of running individual commands multiple times. I'm not entirely sure how to handle this.

Thanks,

Trevor

On Mon, Feb 17, 2020 at 9:08 PM Shawn Wells shawn@redhat.com wrote:

On 2/17/20 8:31 PM, Trevor Vaughan wrote:

The modules are downloaded separately.

Fundamentally, it would be something like the following:

...

# Command $ puppet module install voxpupuli-selinux

# Hiera Data

selinux::enable: true

# Puppet Code include selinux

Alternatively, something like:

# Command $ puppet module install voxpupuli-selinux

# Puppet Code class { 'selinux': enable => true }

What I'm trying to figure out is whether or not this type of thing is OK as a remediation.

The first form is preferred due to complexities.

Well..... not sure how many community members have enough Puppet experience to have an opinion or suggestions. Thanks so much for opening the question on the mailing list though! Hopefully someone does :) Most we could do is likely ask guiding questions.

• What effect would this have for disconnected environments? If someone is

using Puppet, is it assumed that "puppet module install" goes to some on-prem location?

• Could/should we put module dependencies into a Puppetfile that gets

included when puppet remediations are built?

• If multiple rules attempt to install the same module, will each "puppet

module install" attempt to redownload the same module? Or will it say something like "already installed" and continue? _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...

I did look at the existing material and it was more bash-esque than Puppet-centric in most cases.

I'll try to get a PR together and we can go from there but I think you've answered my question to the point where I have confidence that it won't be wasted work.

Thanks,

Trevor

On Thu, Feb 20, 2020 at 10:04 AM Matěj Týč matyc@redhat.com wrote:

We have some Puppet remediations, and even some puppet templates, so you can check them out - run

find . -name '*PUPPET*' find . -name '*.pp'

in the project root.

I feel that this is similar to Ansible remediations, in which case we ship playbooks, assuming that respective modules are available for the consumer of that remediation, or that they know what to do to get them (in case of Ansible that would be to upgrade to the supported version).

I am not sure about Puppet, but your original question about self-contained remediations looks differently now - I think that mentioning somewhere what are the prerequisites could do the trick (e.g. something like Puppet>=6.0 with this and that modules installed). In other words, I wouldn't try to produce Bash that would install that module and then run that remediation - I would leave the prerequisite to the sysadmin. On 18. 02. 20 2:31, Trevor Vaughan wrote:

The modules are downloaded separately.

Fundamentally, it would be something like the following:

...

# Command $ puppet module install voxpupuli-selinux

# Hiera Data

selinux::enable: true

# Puppet Code include selinux

Alternatively, something like:

# Command $ puppet module install voxpupuli-selinux

# Puppet Code class { 'selinux': enable => true }

What I'm trying to figure out is whether or not this type of thing is OK as a remediation.

The first form is preferred due to complexities.

Thanks,

Trevor

On Mon, Feb 17, 2020 at 5:20 PM Shawn Wells shawn@redhat.com wrote:

...

On 2/17/20 5:06 PM, Gabe Alford wrote:

...

Are they modules default in Puppet or are they custom or downloaded separately? If they are default in a standard Puppet install, it should be no problem as that is what we do with Ansible tasks.

And if they're custom, there are always the jinja templates. For example:

https://github.com/ComplianceAsCode/content/blob/master/shared/macros-ansibl...

https://github.com/ComplianceAsCode/content/blob/master/shared/macros-bash.j... _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...

-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --

---

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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedor...