Whonix ™ Security Roadmap
Whonix aims to incorporate an advanced security model designed to defend against evolving threats. The current state of desktop Linux is insufficient.   As such, we have a lot of work to do. This page describes the goals, current status and limitations of our work. Dedicated wiki pages go over each subproject in more detail.
Remember that most of the things discussed here are still in development are not used by default. Contributions and testers are welcome.
Principle of least privilege
Vulnerabilities in software are inevitable. The impact of such vulnerabilities must be contained by isolating processes. We aim to heavily follow principle of least privilege [archive] and security by isolation [archive].
To begin with, we are developing a full system AppArmor policy to confine all user space processes on the system. This will serve as the foundation of our security model and allows us to implement strict mandatory access control restrictions on all processes and have fine-grained controls over what they can access. This follows design ideas already present in other operating systems such as Android and attempts to make something similar available on desktop Linux. In addition to locking down user space, this also protects the kernel as it restricts access to kernel interfaces like
/sys, making kernel pointer and other leaks much less likely.
Furthermore, applications will be executed inside sandbox-app-launcher. This runs each application as its own user, in a bubblewrap sandbox and confined by AppArmor with a robust permission model. The majority of applications that users install will be automatically configured to use sandbox-app-launcher. This includes end-user applications such as web browsers, messengers and so on but not lower-level system utilities.
However, the main issue with both of these technologies is that the desktop Linux software stack was not written with isolation in mind. We cannot be as restrictive as we would like to be without breaking the system. This is in comparison to, for example, Android in which the entire operating system and application ecosystem are designed around SELinux and the application sandbox.   
- https://github.com/Whonix/apparmor-profile-everything [archive]
- https://github.com/Whonix/sandbox-app-launcher [archive]
User space exploit mitigations
Mitigating common classes of vulnerabilities and exploit techniques is also part of our agenda but we are currently unable to do much in this area.
Mainly, we use hardened_malloc to provide strong protections against heap memory corruption vulnerabilities. We aim to preload this globally by default.
Moreover, sandbox-app-launcher enforces strict W^X to prevent attackers from executing new arbitrary code. This will force attackers to utilize the already existing code (e.g. Return-oriented programming (ROP) [archive] / Jump-Oriented-Programming (JOP) [archive]) which is much more limited and difficult. Unfortunately, some applications (mainly web browsers due to JIT) must be whitelisted and currently, there is no protection for system services that run outside of sandbox-app-launcher — it is unclear how this could be implemented (we could add our own seccomp wrapper, wait for S.A.R.A. [archive], use systemd's
Other mitigations such as CFI [archive], SafeStack [archive], automatic stack variable initialization [archive] and so on are highly desirable but unlikely to be utilized due to the current resources of the project.
- Sandbox-app-launcher, Sandbox Escape Mitigation
- Hardened Malloc Kicksecure
- https://github.com/GrapheneOS/hardened_malloc [archive]
Securing user space alone is not enough and it leaves the kernel as a soft target. We are developing hardened-kernel and security-misc in attempt to improve the state of kernel security.
We also use Linux Kernel Runtime Guard which helps against off-the-shelf malware but will not help against a dedicated adversary as it is not hard to bypass.
- Linux Kernel Runtime Guard LKRG
- https://github.com/Whonix/hardened-kernel [archive]
- https://github.com/anthraxx/linux-hardened [archive]
Even if malware is capable of bypassing our other protections, we aim to prevent it from persisting. Verified boot will be used to verify the boot chain and base system, likely by chaining UEFI Secure Boot with dm-verity. This will be difficult to achieve due to the layout of traditional desktop Linux distributions. Once this is implemented, there will be 2 main remaining vectors for malware persistence:
- Malware residing in persistent state.
- Malware residing in the device firmware.
(1) can be solved with apparmor-profile-everything and sandbox-app-launcher. We can severely reduce the level of trust granted to persistent state so that malware residing within there can't do any serious harm and is contained within its own sandbox.
(2) cannot be solved by us. Users will have to use solutions such as Intel Boot Guard [archive] or AMD Secure Boot [archive] (different from UEFI Secure Boot) to verify the integrity of the firmware. Unfortunately, these are not very common.
We currently have a best-effort, albeit quite weak approach. VirusForget tries to deactivates malware after a reboot from a non-root compromise by restoring sensitive files. This prevents malware from persisting through files such as ~/.bashrc. However, this is not a strong defence and will not stand against an active adversary.
- remount secure
- SUID Disabler and Permission Hardener
- Reduce Kernel Information Leaks
- multiple boot modes for better security (user, live, secureadmin, superadmin)
- Fixing the Desktop Linux Security Model [archive]
- About Computer (In)Security
- Testers for New Security Features Wanted!
- https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172 [archive]<
- https://madaidans-insecurities.github.io/linux.html [archive]
- https://source.android.com/security/selinux [archive]
- https://source.android.com/security/app-sandbox [archive]
- https://www.blackhat.com/docs/us-17/thursday/us-17-Kralevich-Honey-I-Shrunk-The-Attack-Surface-Adventures-In-Android-Security-Hardening.pdf [archive]
- https://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ [archive]
- https://grsecurity.net/~spender/interview_notes.txt [archive]
- https://seclists.org/oss-sec/2017/q2/583 [archive]
- https://grsecurity.net/10_years_of_linux_security.pdf [archive]
This is a wiki. Want to improve this page? Help is welcome and volunteer contributions are happily considered! Read, understand and agree to Conditions for Contributions to Whonix ™, then Edit! Edits are held for moderation. Policy of Whonix Website and Whonix Chat and Policy On Nonfreedom Software applies.
Copyright (C) 2012 - 2021 ENCRYPTED SUPPORT LP. Whonix ™ is a trademark. Whonix ™ is a licensee [archive] of the Open Invention Network [archive]. Unless otherwise noted, the content of this page is copyrighted and licensed under the same Freedom Software license as Whonix ™ itself. (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.