dev-sec definitions: linux-hardening, ssh-hardening etc.

[bbros-dev]

Thank you for all the effort put into goss, and for making it open source.

Context: We currently use chef-zero and inspec and are looking to migrate to salt and goss as we migrate we thought to try and contribute to the salt/goss communities in a way they value....

Is there any effort underway to port the dev-sec defintions/descriptions/specifications to goss?

If not; any thoughts on where this is best housed: up-stream dev-sec, wherever, etc.?
Any thoughts on how best to go about this from a goss pov?

Our 2c:

• We don't have any objection to adopting the upstream convention of placing (Goss YAML) files under controls folder and proposing their inclusion upstream. Whether upstream would accept them is a separate question. The goss project could distribute those controls as a git subrepo in a controls folder - giving a user one less thing to do to have access to "reasonable" hardening settings - where "reasonable" is defined by upstream dev-sec.
• We also think it it reasonable to propose to upstream goss-linux-hardening, etc. as repository names under the dev-sec org. Thoughts?

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bbros-dev]

not stale.

[jay7x]

JFYI, you may find some sec-related checks here:

• https://gitlab.com/kevinreed/goss-security
• https://gitlab.com/kevinreed/goss-stig

[uk-bolly]

FYFI

There are also some more found here:

• https://github.com/ansible-lockdown/RHEL8-STIG-Audit
• https://github.com/ansible-lockdown/RHEL7-STIG-Audit
• https://github.com/ansible-lockdown/RHEL8-CIS-Audit
• https://github.com/ansible-lockdown/RHEL7-CIS-Audit

These are standalone configs but can be run in conjunction with Ansible.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bbros-dev]

not stale.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ekelali]

Hello,

I'm doing some maintenance until @aelsabbahy takes back over.

This issue seems interesting as cis-benchmarks seems like a great usecase for Goss.

My suggestion would be for the goss-cis-benchmark repo to live under dev-sec org and any blockers be opened as an issue on Goss repository.

I would assume the latest release of Goss wouldn't cover all the tests without some command tests. The v4 branch might fare a little better. That said, it would be great to identify all the gaps and see if Goss can support all of them natively.

If you've done any of this research already, please post your findings and link the issues here, I'll make sure stale bot doesn't close them out.

A quick search through GitHub shows that others may have done some work already on this:

https://github.com/NeowayLabs/goss-cis-benchmark

Thanks

[uk-bolly]

Hi @ekelali

@MindPointGroup we have been developing the CIS and STIG benchmarks using goss for some time based on the links below for both linux and windows (to be released soon) OS's.
We have found goss to be an excellent product to work alongside the remediation roles that we maintain, to confirm things are working as expected and to provide a very quick gap analysis on a system as well the ability to quickly check for config drift.

I am sure there are improvements our configurations as it stands right now that we welcome feedback on.

You are correct it does require some command tests and we are sure it always will going forward but there are some enhancements we are sure that could be added to the current modules to assist with some of the compliance checks that can be added. We are keen to work on this going forward and enhance this excellent product even further.

We haven't created any issues as yet due to how quiet the repository has become and the issues that already exist not yet having been incorporated and just going stale.

These are the CIS links but we do maintain STIG/DISA in the same org

https://github.com/ansible-lockdown/RHEL8-CIS-Audit
https://github.com/ansible-lockdown/RHEL7-CIS-Audit
https://github.com/ansible-lockdown/UBUNTU18-CIS-Audit
https://github.com/ansible-lockdown/UBUNTU20-CIS-Audit

thanks

[ekelali]

Hello @uk-bolly ,

The attached repos look great, awesome work! Just to be clear, I assume this is a working implementation using the latest Goss release and not a fork, correct?

If possible, I would love to discuss your ideas and concerns and see if we can turn those into action items (read: github issues).

Also, when listing the issues can you provide some details on priority (what's most painful, what provides most value, etc.) and whether any issue was a blocker for your team and/or current workarounds.

Thanks

[uk-bolly]

hi @ekelali

This is purely the latest release not yet forked.

Sorry for the delay in response, We are hoping to do some more work on the repos over the next couple of weeks, as we all get back to working with goss daily again we hope to add the relevant issues.

Thanks

uk-bolly

[aelsabbahy]

Hello @uk-bolly,

Following up on this. I see quite a bit of work has been done on the tests you maintain over the past few months.

If possible, I would love to discuss your ideas and concerns and see if we can turn those into action items (read: github issues).

I would love to get more information on this and see if there are enhancements that align with the goals of goss.

https://github.com/aelsabbahy/goss/blob/master/.github/CONTRIBUTING.md#feature-requests

Also, if stale bot (which is has been disabled for a few months now) has closed out an issue that you were interested in, we can re-open it for further discussion if it alignes.

Thanks,
Ahmed

[uk-bolly]

hi @aelsabbahy

Thank you for following up and what is a very clever and extremely useful project.
As you can see we are using it in quite a unique way and it does work for the whole very well.
I have one issue open which is #724 . This is really the biggest issue as i have to isolate each test as they relate to a rule i am not able to e.g. test the existence of content in the same file across different rules.
That would extend the functionality for me amazingly and allow me to use the module you have built more rather than converting all to use the command module.

There are a few others that i have in mind including the ability for something to return as true and run the next test. Although unsure on how that could be approached. But i know there are many ways to skin a cat and sure others have a similar thoughts or requirements.

Thinking maybe a working group could be a good idea? We've been trying to build the community up for my content by using a discord group.

Thank you again

uk-bolly

[aelsabbahy]

Hello uk-bolly, thank you for the kind words. This use-case is one I had in mind for a long time now, but never had the time to take it on.

I assume the issue you're referring to is this one #742 :)

Would the file test be sufficient to unblock you, or did you need it for all tests to be unblocked?

There are a few others that I have in mind including the ability for something to return as true and run the next test. Although unsure on how that could be approached. But i know there are many ways to skin a cat and sure others have a similar thoughts or requirements.

I don't think I fully understood this request. Can you expand on it a bit more, or give an example usage. Perhaps some high-level YAML examples. Honestly, I'm interested in hearing all the ideas.

[uk-bolly]

HI @aelsabbahy

You are most welcome and you deserve it, it is a great project.
Spot on a good catch it was indeed #742

I use all the modules where i can so long as they have some way of giving it another unique identifier and don't override other testing results already captured that would be brilliant.

With regard to the random thought i will add more context and add a feature request and get the conversations going.

Thank once again

uk-bolly

[aelsabbahy]

Hello @uk-bolly wondering if this particular issue is completed at this point.

#742 was closed by v4 and #843 should help with warnings.

Anyways, let me know if there's still anything actionable on this particular issue and if any other issues are high priority for you. Also, feel free to ping me on slack if you'd like a more "working group"/discussion to hash out some ideas before we formalize them into issues. Issues are fine too if that's your preference.

[uk-bolly]

hi @aelsabbahy

Superb fix really helps with the work we are doing, v4 is a great release.
Thank you again for all your work on this.

many thanks

uk-bolly