Whonix ™ Security Roadmap

From Whonix

(Redirected from Whonix Security Model)


Whonix aims to incorporate an advanced security model designed to defend against evolving threats. The current state of desktop Linux is insufficient. [1] [2] 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[edit]

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 /proc or /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. [3] [4] [5]

User space exploit mitigations[edit]

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 MemoryDenyWriteExecute, etc.).

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.

Kernel hardening[edit]

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.

We are unable to completely fix the issues within the kernel as they are rooted deep within its design and upstream is not very focused on serious security enhancements. [6] [7] [8] [9]

Malware persistence[edit]

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:

  1. Malware residing in persistent state.
  2. 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.


Forum Discussion[edit]

See also[edit]


text=Jobs in USA
Jobs in USA

Search engines: YaCy | Qwant | ecosia | MetaGer | peekier | Whonix ™ Wiki

Follow: 1024px-Telegram 2019 Logo.svg.png Iconfinder Apple Mail 2697658.png Twitter.png Facebook.png Rss.png Reddit.jpg 200px-Mastodon Logotype (Simple).svg.png

Support: 1024px-Telegram 2019 Logo.svg.png Discourse logo.png Matrix logo.svg.png

Donate: Donate Bank Wire Paypal Bitcoin accepted here Monero accepted here Contriute

Whonix donate bitcoin.png Monero donate Whonix.png United Federation of Planets 1000px.png

Twitter-share-button.png Facebook-share-button.png Telegram-share.png link=mailto:?subject=Whonix Security Roadmap&body= link= Security Roadmap link= Security Roadmap link= Security Roadmap%20 Security Roadmap

Love Whonix ™ and want to help spread the word? You can start by telling your friends or posting news about Whonix ™ on your website, blog or social media.

https link onion link

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.

Whonix ™ is a derivative of and not affiliated with Debian [archive]. Debian is a registered trademark [archive] owned by Software in the Public Interest, Inc [archive].

Whonix ™ is produced independently from the Tor® [archive] anonymity software and carries no guarantee from The Tor Project [archive] about quality, suitability or anything else.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent. Whonix ™ is provided by ENCRYPTED SUPPORT LP. See Imprint, Contact.

By using our website, you acknowledge that you have read, understood and agreed to our Privacy Policy, Cookie Policy, Terms of Service, and E-Sign Consent.