Desktop/Workstation hardening for Fedora and its downstream distributions (CentOS Stream, AlmaLinux, RockyLinux). From some perspective, it's not hardening but changing the system's "approach to compromises" towards an "approach" that achieves "harder outcomes" through only considering a narrower user group (average desktop/workstation audiences/use cases) in "compromises" in order to create more "predictable" outcomes for this user group (at the best, no attack surface and no broken applications, for this user group). Once activated, the tools are self-updating, and are to be aligned over time with changing Fedora (and kernel) configurations/policies and their evolvement.
The development on this project is currently ceased due to an unfortunate mix of up- and downstream issues. It is NOT production ready!
Be careful in using this: consider it experimental. harden should undergo some more (partially security-related) code improvements before using it in production (working but still largely a draft). 99-kernel-hardening.conf is fine to use if you keep up with relevant ongoing developments on your OS yourself (no self-update obviously:) -> this argument applies as of 5.6.26. Concerning all other files: you should know what you are doing (and what these files are doing). Parts of this project may be be further developed separately under the umbrella of the Fedora Security SIG, but that would take place in their Forge repos.
If you are interested in a collaboration and to work on this, feel free to reach out to discuss the issues and possible mitigations: #security:fedoraproject.org (Matrix), github issue ticket or email (see my github page if you are logged in).
This tool aims to harden (and achieve predictability in) average private and professional real world desktop/workstation use cases that have different needs than traditional hardening: the sudo user and the major user of the system are equal, and all value of the system is within their one user account. Having access to the data of that user account and its processes makes further protection of the system obsolete: the binaries can be donwloaded freely anyway :) At the same time, origins of attacks are likely to also rise directly/indirectly from this one account. Sudo rights might not always be used by a trained admin. Still, the User Experience of average use cases shall not be broken: a denial of service can be as dangerous as some attacks.
Therefore, the major goal shifts from protecting the system from its accounts to protecting the GUI-using accounts from everything else of the system (e.g., to add protection against half-administrated half-understood services/processes the user deployed intentionally or by accident), and to protect processes within the GUI-using accounts from each along with their data. The goal includes protecting stored data (not equal to the memory of processes) within the accounts from processes that should not have access to it (regarding the latter, the default of Fedora & downstream, if properly setup, facilitate already most that can be done; more improvements for this are planned for the future, but wome of these means will be restricted to flatpak-users).
From some perspective, it's not hardening but changing the system's "approach to compromises" towards a "harder" one that might create more "predictable" outcomes for "average desktop/workstation audiences/use cases": from "deploy the least common denominator by default" to "emphasize the majority and otherwise let it break so that the user knows and can decide themselves which compromise they prefer". Average users should not end up with making decisions about compromises though: they shall be covered by the average use cases that are facilitated without issues anyway. It can be also said this tool just narrows the interests considered in the compromises and emphasizes major-use-case-audiences and audiences who cannot make optimal compromises (short and long term) for themselves (the latter audience is usually covered by the first), which also allows a more explicit security model and hardening as far as it does not break these user experiences. This can support risk management in general, and reduce transaction costs in professional deployments.
The hardening tool is self-updating its hardenings as long as the rpm from which it is installed is updated as well (e.g., through the normal daily updates with dnf): if the community has to make changes in its "deploy the least common denominator by default" compromises, the tool can adjust its "hardened" systems adaptively and automatically in parallel towards the above mentioned compromise approach: no user interaction necessary. Communities have to find compromises that fit for many user groups / audiences, and some of the compromises can lead to outcomes that are disadvantageous for some of the user groups but are a demand for another: the tool keeps the users' systems focused, mitigating conflicts that can have perceived or hidden impacts.
The hardening tool aims to be usable by all audiences, including beginners: it can be deployed "fire and forget" and is self-updating its hardening. Installation is easy: install the tool + run one copy/paste command to activate the tool (and another copy/paste command to test it, and another to deactivate it).
The focus is that average use cases do not break and always work by default (browser, email, desktop/GUI, office, etc.), and average users should not be bothered with broken processes/tools. Yet, some tools that are not deployed by the average user / majority and that can cause trouble to others might be broken: so far, the hardening tool breaks software development tools like gdb or strace because the ptrace they use can be also used by processes to steal data from other processes (e.g., a manually installed untrusted application could steal credentials used in the browser, stored unencrypted in it's memory during runtime, even if otherwise encrypted on disk): the hardening tool assumes that software developers who deploy this tool would be able to identify the issue and solve it by finding a tailored compromise for themselves. The attempts to overwrite the system default by packages like gdb and strace and their dependencies, to facilitate ptrace, will be likewise overwritten by the hardening! So ptrace will remain disabled!
With this in mind, the files of the tool contain many comments that sufficiently detail what happens where and allow more advanced users to modify contents if they want (e.g., disable the lines that break gdb or strace), and if preferred, allow to just deploy some files or lines manually to fit their personal compromises: in order to facilitate users without dev experience to the files, classes and methods are intentionally avoided (and not necessary for the use cases of the tools anyway).
Keeping lines and functions simple, at the best the level that people without coding experience can make sense of it just with advanced command line experience and general understanding of spreadsheet-IF/ELSE might also help to get a wider audience to help testing and add a broader knowledge to improvements: the tools have already proven useful to also find bugs in gdm/gnome and systemd.
At the moment, this tool should NOT be used on systems that make use of SELinux Confined Users: while enabled, the SELinux User Confinement customizations of the system admin can become adjusted towards the policy of Fedora Downstream Hardening, and disabling will inevitably reset the SELinux User Confinement configuration to the default. If system admins of a system do not know of the command semanage login ..., they can expect to be not affected by this. This is no default on any Fedora nor any downstream distribution.
Once available as package on Fedora and EPEL, the tool can be installed with dnf install fedora-downstream-hardening: keep in mind that CentOS Stream, Rocky, Alma might need you to enable EPEL manually in advance if you have not already done so. The tool will not be active or harden anything just by installing it with dnf!
But once installed, you can do (as root or with sudo) harden activate: if the output then says the hardening worked out, your system is hardened once you rebooted. It is suggested to run the selftest after rebooting in order to verify the hardening has worked out: harden selftest. If this leads to an error output, please read the instructions of the error output and follow them properly: you can open a ticket about this here.
In order to ensure that active hardenings are properly updated, the package fedora-downstream-hardening will be protected from removing as long as the hardening is active.
To remove the hardening and the package again, you need to do the following two commands in this very order: first, harden deactivate and then dnf remove fedora-downstream-hardening: after rebooting, your system is back to the earlier defaults.
There is also harden activate-noexec-now and harden deactivate-noexec-now: this does not protect against malicious or untrusted people, because if they have basics in how Linux works, these means can be easily bypassed by them. Instead, this is to support trusted but maybe inexperienced or unperceptive people/users. This can mitigate, e.g., many cases in which users would intuitively open files in emails, which then prove to be malicious executables. This is intentionally not integrated into harden activate because it can break a lot: self-installed applications (e.g., python tools from pip) or flatpaks on the user level, will likely be broken. This is useful only if the user is not intended to install anything nor to download and run executable files at all.
Keep in mind that the name of the tool might change before its release!
At the moment, only x86_64 architectures are considered: while the tool is likely can be deployed on ARM-based architectures too, some or all of the kernel parameter (security features) might be not available there.
It has been tested and works out fine, but it is not yet recommended to use this tool in a production environment! More testing is necessary! Fedora-downstream-hardening should be considered testing until version 1.0 has been released!
Tests with 0.8 have been done with Fedora 43 KDE, Fedora 43 Kinoite, CentOS Stream 10 KDE, CentOS Stream 10 GNOME, AlmaLinux 10 GNOME, RockyLinux 10 KDE. All mentioned systems, each with GNOME and KDE (from EPEL) will be supported upon release (plus RockyLinux 10 GNOME and AlmaLinux 10 KDE). Support will be limited in all cases to the newest release of the respective OS!
Currently, the development of this tool has identified 2 bugs: systemd #41599, selinux/gdm BZ#2461112. Implications below.
systemd bug affects one task in one context: systemd bug #41599 can lead to unconfinehomeusers not being triggered if several user accounts are created quickly after each other. Occurrences of the bug are realistic if less than usually ~5 seconds pass in between user account creations (low-end/old hardware might need more seconds in between): only the 2nd and subsequent accounts can be affected. This issue can be mitigated by running - after all new user accounts have been created - once manually sudo unconfinehomeusers. The bug is known and to be solved in future systemd releases (no updates of Fedora-downstream-hardening will be necessary for this bug). The bug is unlikely to be relevant for the targeted user groups, and the worst case that can happen is that one or some accounts have the same security level as a default Fedora. This issue will be automatically corrected on the next invocation of unconfinehomeusers, may it be manually or automated.
All F43 and F44 variants with GNOME or KDE are partially or fully broken if __default__ is mapped to user_u, F44 KDE-variants also with staff_u due to selinux/gdm BZ#2461112 (most details in the preceding forge ticket). This bug and its implications show that Fedora testing currently lacks the capacity to reliably identify bugs and policy issues around SELinux Confined Users. Therefore, the confinement approach is changed in order to avoid DoS-like impacts on users after updates: unconfined_u remains the default, and only accounts that fulfill certain criteria become confined to user_u. Version 0.9 candidates seem to be not affected by this bug.
More evaluation of the selinux/gdm bug and review necessary before release.
PEP 8 compliance mostly implemented, and to be improved over time. Files are intentionally written/kept as simple as possible, not emphasizing code efficiency or so (at the best, sufficiently understandable by everyone with general understanding of working with the command line and general understanding of IF/ELSE and clauses known from spreadsheets). This tool aims to not break the review/testing guarantees created in the development process of the OS.
<major release>.<minor release>
-> major release: new security functions added -> it is not possible to always prove that this does not break anything in any context. Therefore, it needs to be obvious in the versioning. Also, it can in some cases be that Fedora enables functions that are not yet existing or not yet useful downstream: so at the worst, two major releases with each its own minor releases are temporarily necessary.
-> minor releases: bug fixes, improving comments/text, disabling security functions (obsoleted or replaced or broken etc.)
-> releases that apply not to all downstream, fedora <-> EPEL(centos, alma, rocky), might be marked additionally with "fedo" (fedora) or "epel" (centos, alma, rocky): e.g., "2.5fedo" and "1.8epel". If it becomes necessary to have differences in the hardening configurations within the EPEL-using downstream, this must be implemented within the files of the very release.
-> tagging all in "main", but a branch for each release (including each fedo/epel release) -> useful to maintain differences of fedo/epel releases independently. This is likely to become relevant when, e.g., Fedora gets new relevant kernel functions that are not yet available in the EPEL-using downstream kernels.
-> 0.n (with the 0 in the beginning) implies no full release yet (= not yet eligible for production)
This repository and its files are licensed under the GNU General Public License, either version 2 of the License, or (at your option) any later version.