Whonix ™ Security Roadmap
From Whonix
Introduction[edit]
Whonix ™ aims to incorporate an advanced security model designed to defend against evolving threats. Most if not all desktop Linux distributions in their current state provide insufficient protection. [1] [2] These issues are unspecific to Whonix ™. As such, Whonix ™ developers have a lot of work to do. This page describes the goals, current status and limitations of our work. Dedicated wiki pages outline each sub-project in further detail.
Readers should note that most of the topics discussed here are still in development and are not yet used by default. Contributions and testers are most welcome.
Future Enhancements[edit]
Principle of Least Privilege[edit]
Vulnerabilities in software are inevitable, therefore their impact must be contained by isolating processes. The Whonix ™ design has adopted the principle of least privilege [archive] and security by isolation [archive] concept in order to mitigate security threats.
Firstly, a full system AppArmor policy is in development to confine all user space processes on the system. This will be foundational to the security model and allow the implementation of strict mandatory access control restrictions on all processes, as well as finer-grain control over what they can access. Essentially desktop Linux can imitate design ideas already present in other more robust operating systems like Android (issues with Android). In addition to locking down user space, this also protects the kernel because it restricts access to kernel interfaces like /proc or /sys, reducing the likelihood of kernel pointer and other leaks.
Furthermore, applications in the future will be executed inside sandbox-app-launcher. This runs each application as its own user, inside a bubblewrap sandbox and confined by AppArmor with a robust permission model. The end goal is most user-installed applications will be automatically configured to utilize sandbox-app-launcher, including common applications like web browsers and messengers (but not lower-level system utilities).
The main drawback of this approach is the desktop Linux software stack was not written with isolation in mind. A delicate balance is necessary when restricting processes so user applications and the desktop OS remain fully functional. This stands in stark contrast to operating systems like Android which were designed to contain the entire operating system and application ecosystem with SELinux and the application sandbox. [3] [4] [5]
Further reading:
- Apparmor-profile-everything
- Sandbox-app-launcher
- GitHub:
apparmor-profile-everything[archive] - GitHub:
sandobx-app-launcher[archive]
User Space Exploit Mitigations[edit]
Mitigating common classes of vulnerabilities and exploit techniques is also on the Whonix ™ security roadmap, but the possible mitigations are limited at present. In the main, hardened_malloc is planned to provide strong future protection against heap memory corruption vulnerabilities; the intention is to preload this globally by default.
Moreover, sandbox-app-launcher enforces a strict W^X ("write xor execute") [archive] policy [6] to prevent attackers from executing new arbitrary/malicious code. This will force attackers to utilize the already existing code -- for example Return-oriented programming (ROP) [archive] / Jump-Oriented-Programming (JOP) [archive] -- which is far more limiting and difficult to achieve. Unfortunately, some applications (mainly web browsers due to just-in-time compilation (JIT) [archive]) [7] [8] [9] must be whitelisted. Currently, there is no protection for system services that run outside of sandbox-app-launcher — it is unclear how this could be implemented. Whonix ™ could possibly add its own seccomp wrapper, wait for S.A.R.A. [archive], use systemd's MemoryDenyWriteExecute, or other measures.
Additional mitigations like CFI [archive], SafeStack [archive], automatic stack variable initialization [archive] and others are highly desirable but are unlikely to be utilized due to current project resourcing.
Further reading:
- Sandbox-app-launcher: Sandbox Escape Mitigation
- Hardened Malloc Kicksecure
- GitHub: GrapheneOS/hardened_malloc [archive]
Kernel Hardening[edit]
Securing user space is a worthy security goal, but it is insufficient in isolation because it leaves the kernel as a soft target. In response Whonix ™ is developing hardened-kernel and security-misc in an attempt to improve the state of kernel security. Linux Kernel Runtime Guard is also used to help defend against off-the-shelf malware, but it will not help against dedicated or advanced adversaries because it is not difficult to bypass.
Whonix ™ is unable to completely address kernel security issues because they are rooted deep within its design and upstream developers are not very focused on serious security enhancements; see footnotes. [10] [11] [12] [13]
Further reading:
- Linux Kernel Runtime Guard (LKRG)
- Hardened-kernel
- GitHub:
hardened-kernel[archive] - GitHub:
linux-hardened[archive]
Malware Persistence[edit]
If malware is capable of bypassing other protections, Whonix ™ aims to prevent it from persisting. In future, verified boot will be used to verify the boot chain and base system, likely by chaining UEFI Secure Boot with dm-verity [archive]. [14] This will be a difficult endeavor due to the layout of traditional desktop Linux distributions. Once this is implemented, there will be two main remaining vectors for malware persistence:
- Malware residing in a persistent state.
- Malware residing in the device firmware.
The first problem can be largely solved with apparmor-profile-everything and sandbox-app-launcher. By severely reducing the level of trust granted to the persistent state, the threat of serious harm from any resident malware is reduced and it is contained within its own sandbox.
The second problem cannot be solved by the Whonix ™ project. Instead, users need to rely on solutions like Intel Boot Guard [archive] or AMD Secure Boot [archive] (different from UEFI Secure Boot) to verify the integrity of the firmware. Unfortunately these options are not very common.
Whonix ™ has adopted a best-effort, but admittedly quite weak approach. VirusForget attempts to deactivate 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 defense and it will not defeat the efforts of an active adversary.
Further reading:
Additional Security Measures[edit]
- Remount Secure
- SUID Disabler and Permission Hardener
- Reduce Kernel Information Leaks
- Multiple Boot Modes for Better Security (user, live, secureadmin, superadmin)
Forum Discussion[edit]
See Also[edit]
- Fixing the Desktop Linux Security Model [archive]
- About Computer (In)Security
- Testers for New Security Features Wanted!
Footnotes[edit]
- ↑ Fixing the Desktop Linux Security Model [archive]
- ↑ Linux (In)security [archive]
- ↑ Security-Enhanced Linux in Android [archive]
- ↑ Android: Application Sandbox [archive]
- ↑ Honey, I Shrunk the Attack Surface: Adventures in Android Security Hardening [archive]
- ↑
W^X... is a security feature in operating systems and virtual machines. It is a memory protection policy whereby every page in a process's or kernel's address space may be either writable or executable, but not both. Without such protection, a program can write (as data "W") CPU instructions in an area of memory intended for data and then run (as executable "X"; or read-execute "RX") those instructions. This can be dangerous if the writer of the memory is malicious.
- ↑
...(JIT) compilation (also dynamic translation or run-time compilations) is a way of executing computer code that involves compilation during execution of a program (at run time) rather than before execution. Most often, this consists of source code or more commonly bytecode translation to machine code, which is then executed directly. A system implementing a JIT compiler typically continuously analyses the code being executed and identifies parts of the code where the speedup gained from compilation or recompilation would outweigh the overhead of compiling that code.
- ↑ As JIT compilation uses executable data directly in memory, this can lead to exploits if execution is moved into the heap; writable/executable memory is a security hole since code is normally written to memory and marked read-only.
- ↑ JIT leads to a faster browsing experience but opens up a large number of potential exploits, see: Microsoft Launches JIT-Free 'Super Duper Secure Mode' Edge Browser Experiment [archive].
- ↑ Net of insecurity: The kernel of the argument [archive]
- ↑ https://grsecurity.net/~spender/interview_notes.txt [archive]
- ↑ More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method [archive]
- ↑ 10 Years of Linux Security: A Report Card [archive]
- ↑
Device-Mapper’s “verity” target provides transparent integrity checking of block devices using a cryptographic digest provided by the kernel crypto API. This target is read-only.
Whonix ™ is Supported by Evolution Host DDoS Protected VPS. Stay private and get your VPS with Bitcoin or Monero.
|
100px |
| Fosshost | About Advertisements |
Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki
.svg.png&filetimestamp=20200623163525&.html){kind=small}
Are you proficient with iptables? Want to contribute? Check out possible improvements to iptables. Please come and introduce yourself in the development forum.
Priority Support | Investors | Professional Support
Whonix ™ | © ENCRYPTED SUPPORT LP | 
Freedom Software / 
Open Source (Why?)
The personal opinions of moderators or contributors to the Whonix ™ project do not represent the project as a whole.