Proposal: Adding more guides that include information that will require payments to our security documentation

[bennyvasquez]

We've got pretty great security guides on the wiki, but it came up during our recent Microsoft meetup that @sej7278 has pretty great guides and helpful scripts that he's put together that we might want to link to. Some of the guides have Tuxcare-specific stuff in them, though. How do we feel about adding links to those? Perhaps we include a caveat that some of the content might require charges?

[codyro]

If possible, I prefer to keep paid/proprietary stuff out of any officially endorsed guides; otherwise, we're opening a can of worms for any product/service to inundate us with "guides" that are essentially ads for their services, putting us in an awkward situation.

Can Simon separate the TuxCare-specific stuff into another repository or branch? Or conversely, can he make a new one with any AL/EL-agnostic stuff in its own repository with an appropriate license (https://choosealicense.com/)?

Does the license here conflict with any of the TuxCare-specific stuff?

[sej7278]

If we make an AlmaLinux repo to hold it, I can just not upload the STIG i guess, and stick to the CIS benchmarks etc; seems a shame though.

In the meantime if we link to my repo it just mentions using a TuxCare license key to get the FIPS packages etc:

https://github.com/sej7278/virt-installs/blob/master/alma9_stig_ansible/roles/common/tasks/tuxcare.yml

We have a review process (this!) so we don't have to accept guides that are adverts.

[codyro]

I mentioned this to @sej7278 briefly on a call, but if we can have the playbooks either skip over the TuxCare portion(s) if the esu_key isn't defined or prompt the user with vars_prompt to handle it so if the user isn't required to register with TuxCare to follow the tutorial, I'd feel a lot better about this.

Are all of the TuxCare packages listed here necessary (w/ the hardcoded version as well), or can we use some from upstream directly instead?

https://github.com/sej7278/virt-installs/blob/master/alma9_stig_ansible/roles/common/tasks/packages.yml#L56-L63

[sej7278]

Yes the hardcoded packages are in the STIG as they're the FIPS validated versions, plus a couple of updated packages specifically to meet STIG requirements.

I'm still thinking about how we can do something without using the commercial packages, although it won't be a setup that could be used by organisations that actually need STIG compliance, but it should be at least interesting/useful to the community for e.g. security researchers.

[codyro]

I used to use the OSCAP remediation's personally, but I prefer your playbooks after using them. I ended up tweaking a few tasks/tags so I could --skip-tags tuxcare and run through everything sans the commercial portion, which I find very useful. I think a good segment of our users would, too (or something similar), as I/we don't need full compliance in most cases. These playbooks would also see a ton more usage, which would benefit TuxCare/AlmaLinux more in the long run (IMO).

These are too helpful/good not to publish in some capacity, so if you're not comfortable @sej7278 tweaking some things, I think it's fine as long as it's very clear to the user that they will not be able to run these as-is without going through some hoops.

I'd go as far as saying we (me?)/you (if you have time) should write a blog post about their usage, as it's worth highlighting.

[sej7278]

@codyro yes a CIS/STIG blog post sounds like a good idea, i'll work on that and maybe make it coincide with AlmaLinux/almalinux.org#563 by which time the updated benchmark should be published.

Tagging all of the tuxcare-specific bits so they can be skipped (most already are) and writing a README.md for CIS/STIG rather than just the whole repo is on my TODO list and obviously needs to be done before this wiki update.

[codyro]

Tagging all of the tuxcare-specific bits so they can be skipped (most already are) and writing a README.md for CIS/STIG rather than just the whole repo is on my TODO list and obviously needs to be done before this wiki update.

Let me know if I can be of any assistance :).

[sej7278]

I've separated the commercial stuff out (moved all tuxcare tags into tuxcare.yml) and added a README:

https://github.com/sej7278/virt-installs/tree/master/alma9_stig_ansible

For community users it has the caveat that it will upgrade them to 9.4, but its nice to see that the hardening works for 9.x even if the STIG is strictly speaking for 9.2 only (due to FIPS validation) at the moment.

P.S. the CIS benchmark v2.0.0 got published on the 24th and I made a minor update, so the alma9cis stuff can be considered final for that too.

[sej7278]

Shall I do a PR for getting this added to the wiki?

also any idea where to put it e.g.

https://wiki.almalinux.org/documentation/guides.html

https://wiki.almalinux.org/Howto.html#authentication-security

I've really got to get to grips with writing a CIS/STIG blog post, especially with the FIPS news