While many valuable security guides exist, better security and privacy for the masses necessitates software that applies a majority of hardening instructions by default.
This is the reason the Free and Open Source {{project_name_short}} project exist; to offer a system that provides a reasonable security-hardened baseline, with the in-built flexibility to apply additional hardening dependent upon the user's threat model, hardware capabilities, motivation and knowledge. <ref>It is also accepted that no "perfect configuration" exists that can make a system invulnerable against advanced adversaries. Further, systems that are excessively hardened can become almost unusable except for the most advanced individuals.
</ref> The table below provides a further rationale for this position.
'''Table:''' ''Security Guide Limitations''
! scope="col"| '''Factor'''
! scope="col"| '''Description'''
! scope="row"| Initial vulnerability
| When a base system is first installed, various security customizations are not yet applied. All users are vulnerable during this period.
! scope="row"| Recipient insecurity
| Security principles do not exist in a vacuum:
* Even after applying various security hardening steps, correspondence/network partners might have serious, unaddressed vulnerabilities.
* Some security problems cannot be solved by individuals and may rely on factors in the broader ecosystem. For example:
** Advanced adversaries perform continual surveillance of all Internet traffic and attempt to attribute collected meta-data to individuals.
** Following a guide to enhance entropy is insufficient if Tor relays being used are insecure.
** Often personal security can only be improved if the security of others is also improved.
! scope="row"| Reliance on human memory
| Adequate hardening often depends on discovering and remembering to apply all necessary steps from favorite security guides.
! scope="row"| Error risks
| Manually applying security guide steps can lead to mistakes that render the whole procedure ineffective.
! scope="row"| Time requirements
| Security guide steps are often lengthy and cover many different facets of computing.
! scope="row"| Secure guide discovery
| There are countless security/hardening guides available on the Internet. It is impossible to follow them all and serious research is required to find valuable new resources.
! scope="row"| Incompleteness
| Logically there is not one definitive, all-encompassing security guide. This means some users harden the kernel and install CPU microcode updates, while others rely on sandboxing and implement better random number generators, and so on. Most users miss critical elements because they are simply not aware they exist.
| Even the best security guides often contain outdated material. This is especially true for technically detailed or lengthy guides that canvass many topics.
! scope="row"| Publication form
| The form of security guides can effect their utility. For example, those published in blogs and which do not allow comments have grave disadvantages compared to systems relying on collaborative version control software (like git) or collaborative websites (such as a wiki). The reason is contributors can easily fix issues or update contents.
! scope="row"| Popularity
| Security guides which have low popularity cannot effect change and improve security practices if most people are unaware they exist.
For these reasons {{project_name_short}} will remain focused on enabling the majority of (reasonable) hardening settings by default, and allowing additional settings to be easily enforced via installable packages. For further information on this topic, see: [https://forums.whonix.org/t/the-problem-with-security-guides-and-how-we-can-fix-it/8563 The Problem with Security Guides and How We Can Fix It]. Implementation of the Securing Debian Manual
The {{project_name_short}} project has been studying the Securing Debian Manual, is applying operating system hardening by default as much as reasonably possible, and documents its knowledge with updated contents. Unfortunately, the Securing Debian Manual has not been updated in a while <ref>* <code>sysvinit</code> and not mentioning <code>systemd</code>
* <code>initrd</code> and not mentioning <code>dracut</code>
</ref> and is already somewhat dated.
For attribution, the wiki [[Template:Sdebian]] is added to all wiki pages where the Securing Debian Manual has been considered. A list of these pages can be found on [[Special:WhatLinksHere/Template:Sdebian]].
|link=https://www.debian.org/doc/manuals/securing-debian-manual/
{{Anchor|iPhone and Android Level Security for Linux Desktop Distributions}}The {{project_name_short}} development roadmap includes various security improvements:* Many features are already available for testing, see [[Test]] wiki page.
* Encrypted and/or authenticated system-wide DNS (domain name resolution) <ref>
[https://forums.whonix.org/t/use-dnscrypt-by-default-in-kicksecure-not-whonix/8117 use DNSCrypt by default]
</ref> to mitigate against threats from DNS cache poisoning aka [https://en.wikipedia.org/wiki/DNS_spoofing DNS spoofing]. <ref>
DNS spoofing results in traffic being diverted to the attacker's computer (or any other computer).
</ref> See also [[DNS Security]].
{{project_name_short}} Development Goals {{project_name_short}} is a security-hardened Linux Distribution. (<u>Mobile version not planned yet.</u>)This section details potential future security enhancements for {{project_name_short}}.(The wiki source for the following text can be found [[Template:Kicksecure_Android|in Template:Kicksecure_Android]].)
{{project_name_short}} will not implement these kinds of user freedom restrictions since it is not required nor desirable. The capability to replace the operating system or gain administrator access will remain fully supported. Many popular device operating systems utilize security technologies which restrict user freedoms. In contrast, {{project_name_short}} aims to utilize the same security concepts for the goal of empowering the user and increasing protection from malware.It is theoretically possible to provide some of the same iPhone / Android security concepts on a Linux computer too. Steps have already been made to apply mobile device security concepts to Linux distributions such as [https://github.com/{{project_name_short}}/security-misc security-misc] and [https://github.com/roddhjav/apparmor.d apparmor.d]. Security technologies like hardened kernels or verified boot used by popular mobile operating systems could also be ported to Linux distributions. Community contributions are gladly welcomed! Here is a list of potential security enhancements for {{project_name_short}}:* [https://forums.whonix.org/t/multiple-boot-modes-for-better-security-persistent-root-persistent-noroot-live-root-live-noroot/7708 multiple boot modes for better security: persistent user | live user | persistent admin | persistent superadmin | persistent recovery mode]
* [https://forums.whonix.org/t/disable-suid-binaries/7706 Disable SUID Binaries]
* [https://forums.whonix.org/t/re-mount-home-and-other-with-noexec-and-nosuid-among-other-useful-mount-options-for-better-security/7707 (re-)mount home (and other?) with noexec (and nosuid (among other useful mount options)) for better security]
* [https://forums.whonix.org/t/allow-loading-signed-kernel-modules-by-default-disallow-kernel-module-loading-by-default/7880 enforce kernel module software signature verification]
* [[Dev/VirusForget|deactivate malware after reboot from non-root compromise]]
* [https://forums.whonix.org/t/walled-garden-firewall-whitelisting-application-whitelisting-sudo-lockdown-superuser-mode-protected-mode/5725 walled garden, firewall whitelisting, application whitelisting, sudo lockdown, superuser mode, protected mode]
* [https://forums.whonix.org/t/kernel-recompilation-for-better-hardening/7598 Hardened Kernel]
* [[Verified_Boot#Hash_Check_all_Files_at_Boot|Verified Boot]]
* [https://forums.whonix.org/t/signify-openbsd/7842/5 signify signed releases]
* Post-Quantum Cryptography ([[PQCrypto]]) [https://forums.whonix.org/t/use-codecrypt-to-sign-whonix-releases/7844/2 resistant signing of releases]
* [https://forums.whonix.org/t/untrusted-root-does-it-make-sense-to-try-to-improve-security-by-restricting-root/7998 Untrusted Root User]
or create an account