*Editing to tag @py0xc3 for awareness.
This is a review of the Fedora-maintained hardening for general use cases documentation. I recommend that you take a look at this if you care about your machine’s security.
Please be aware, I wrote this elsewhere and formatting is imperfect. So:
• = main bullet
◦ = sub bullet to the main bullet above it
Keep:
• I like the partial CIA (or AIC) triad reference at that beginning.
• I like the note to urging users to read the whole thing because attention spans are pretty short these days.
• Overall, the page content, explanations, and in-line considerations/notes are great. The overall organization and categorization is good (self-updating and enable & forget).
• I like the reverting instructions.
◦ Perhaps, these should also be in a revert summary at the very end in the same self-updating and enable & forget categorizations instead of merely existing “in-line” because they have to be hunted for in current state.
Include/Improve:
• One thing I do want to see on the security doc is a release date when one is decided.
◦ I check on some things when I see systemd updated because I want to use this. I just have not seen anything that indicates that is ready for use at this time apart from manually adding the hardening .conf file. I would prefer not to go the manual route because these settings are pretty hands off (based on the data), and I will eventually forget to remove the manual configuration when the official one releases.
• I think separating each paragraph with a space between them would make it seem less off-putting for non-technical users. Without those spaces, it can look pretty intense and cluttered.
• Bulleted content is easier to digest, but only use them where necessary/applicable.
◦ Sometimes it is impractical to use that type of format, but it may be warranted in the paragraph beginning with “Outside of general use cases, the hardening changes…” because I realized that whole thing is basically one convoluted sentence. I struggle with the same thing sometimes, so I understand the headspace of why it is written like that.
• Consider linking to pages that describe what gdb, strace, and ptrace are.
◦ This is not Arch, but I think the Arch wiki would do something along those lines for those that prefer to enter rabbit holes because these are fundamental to your implementation’s purpose.
• Consider including some links to documentation explaining how a “backup” can be made if the end user later finds that this borks their system’s use cases and/or purpose.
• Consider making “fedoraproject.org, redhat.com and danwalsh.livejournal.com” into hyperlinks.
Questions:
• For the permanent adjustments made by end users to accommodate special needs, how will the “self-updating” kernel hardening handle those configurations that it may have changes for during updates?
◦ Will it ignore them or will it overwrite my permanent settings as an end user?
◦ Will it realize that field is not “null” and pass over it to continue on with the other changes published during an update?
Specific Call-Outs:
• “This does NOT conflict with the kernel hardening above. But the ptrace-disabling measures of the kernel and of SELinux are largely overlapping (not equal though) and act primarily as redundant security layers.”
◦ I like this because it enforces the fact that good security implementations are multi-layered. Security is an approach. Security is not a simple configuration setting.
• “When the hardening is enabled, do NOT file reports for broken applications that depend on ptrace, or for web services that need open ports: they are intentionally broke. Please do NOT file a report until you have verified the hardening is the origin of your issues: in order to find out, please remove the hardening and then reboot (see above about how to disable the hardening means).”
◦ Make this information front and center at the very top of the document. No one wants false positive bug reports for an end user’s oversight or misunderstanding of what they are doing with security implementations or the consequences that result from them.
• “Be careful to know what you are doing when changing SELinux booleans.”
◦ Yes, please draw as much attention to this as possible!
• “Be careful to know what you are doing when enabling “SELinux confined users”. And don’t forget about the limited support!”
◦ Again, very good!
Overall, I think is excellent, and thank you for the work put into this! I think it could even be part (or the start 
) of a larger project. I think it would be stellar to have an official Fedora “STIG” (Security Technical Implementation Guides) site or reference material. Feel free to ask questions, but it may take me some time to get back to you with meaningful responses or opinions.
So that should come automatically once its published.
