Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bennyvasquez opened this issue May 29, 2024 · 9 comments
Labels
question Further information is requested

Comments

@bennyvasquez
Copy link
Member

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?

@bennyvasquez bennyvasquez added the question Further information is requested label May 29, 2024
@codyro
Copy link
Member

codyro commented May 29, 2024

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
Copy link

sej7278 commented May 29, 2024

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
Copy link
Member

codyro commented Jun 10, 2024

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
Copy link

sej7278 commented Jun 10, 2024

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
Copy link
Member

codyro commented Jun 19, 2024

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
Copy link

sej7278 commented Jun 19, 2024

@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
Copy link
Member

codyro commented Jun 21, 2024

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
Copy link

sej7278 commented Jun 26, 2024

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
Copy link

sej7278 commented Aug 5, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants