Debian Security Announcements
Since {{project_name_short}} is based on Debian, it takes advantage of all the hard work done by their security team: <ref>https://www.debian.org/security/</ref>
<blockquote>Debian takes security very seriously. We handle all security problems brought to our attention and ensure that they are corrected within a reasonable timeframe. Many advisories are coordinated with other free software vendors and are published the same day a vulnerability is made public and we also have a Security Audit team that reviews the archive looking for new or unfixed security bugs.
Experience has shown that "security through obscurity" does not work. Public disclosure allows for more rapid and better solutions to security problems. In that vein, this page addresses Debian's status with respect to various known security holes, which could potentially affect Debian.</blockquote>
Users should consider subscribing to the Debian [https://lists.debian.org/debian-security-announce/ security announcement mailing list] to stay informed about the latest security advisories.
|link=https://www.debian.org/doc/manuals/securing-debian-manual/ch04.en.html#debian-sec-announce
|text=Subscribe to the Debian Security Announce mailing list
Most hardening steps cannot be easily added to {{project_name_short}} by default. Any major changes require careful research and significant developer/tester effort, otherwise system errors or breakage may occur. This is an open topic and {{project_name_short}} developers are amenable to suggestions - improving operating system security will always be a primary design goal.Before attempting additional hardening measures below, be sure to fully understand them and apply the steps carefully:
* [https://wiki.debian.org/HardeningWalkthrough Debian Hardening Walkthrough]
* [https://www.debian.org/security/ Debian Security Information]
* [https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html Securing Debian Manual]
** [https://www.debian.org/doc/manuals/securing-debian-manual/automatic-harden.en.html Securing Debian Manual Chapter 6 - Automatic hardening of Debian systems]
Readers are welcome to add any additional hardening resources to this list.
The upstream Kernel Self Protection Project (KSPP) <ref>https://www.openwall.com/lists/kernel-hardening/</ref> was established in 2015 with the goal of introducing more hardening features into mainline Linux. This includes many features found in the Grsecurity patchset, which was [https://www.phoronix.com/news/GrSecurity-No-Longer-Free publicly available until early 2017]. One advantage of KSPP is that users will no longer need to compile and tweak settings to create a secure kernel. Instead, many hardening features will become the default over time in various distributions. Up-to-date information on available hardening features can be viewed [https://github.com/a13xp0p0v/linux-kernel-defence-map here].
The Hardened Kernel Project is a collaborative effort between Arch and Gentoo developers who handled Grsecurity packaging in their respective distributions with the goal of accelerating mainlining of the patchset. <ref>https://github.com/GrapheneOS/linux-hardened/wiki</ref> <ref>https://github.com/anthraxx/linux-hardened</ref>
While kernel hardening is important, it only addresses a subset of security risks. It cannot protect against backdoors or security issues related to design, policy or yet unknown exploit classes.
Restricting module loading can protect the kernel.
Chapter "Module Loading" is for advanced users only since it could break various things. This is still under development. See {{project_name_short}} development discussion: [https://forums.whonix.org/t/allow-loading-signed-kernel-modules-by-default-disallow-kernel-module-loading-by-default/7880 allow loading signed kernel modules by default / disallow kernel module loading by default]<code>/usr/lib/modules-load.d/firewall.conf</code>
<code>/usr/lib/modules-load.d/xfce.conf</code>
## is autoloaded by snd_intel8x0
{{project_name_workstation_long}} only: <code>/usr/lib/modules-load.d/kloak.conf</code>VirtualBox only: <code>/usr/lib/modules-load.d/vbox.conf</code>
Disable module loading by creating this file: <code>/etc/sysctl.d/module-loading.conf</code>
kernel.modules_disabled=1
After reboot, test if module loading is really disabled. Try to load any module, for example <code>apanel</code>.
modprobe: ERROR: could not insert 'apanel': Operation not permitted
Harden Software Repositories
Many operating systems provide multiple repositories. Since the {{project_name_short}} implementation is based on Debian, these resources provide a suitable introduction for interested readers:* [https://www.debian.org/doc/debian-policy/ch-archive.html Debian Policy Manual Chapter 2 - The Debian Archive].
* [https://help.ubuntu.com/community/Repositories/ Ubuntu Repositories (similar to Debian)].
In summary, these resources confirm the main repository receives the most developer attention and security updates. This suggests a degree of hardening might involve editing ''/etc/apt/sources.list'' to strictly limit software to the main repository, while only installing security fixes and no other updates.
{{project_name_short}} has <u>not</u> implemented this design by default and it is an open research question whether this will actually improve security.
or create an account