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

[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.

[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.

[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

[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.