{{Header}}
{{title|title=
{{project_name_long}} Security Roadmap
}}
{{#seo:
|description=Future {{project_name_short}} Security Enhancements
|image=Roadmap.jpg
}}
{{about_mininav}}
{{intro|
Future {{project_name_short}} Security Enhancements
}}
[[File:Roadmap.jpg|thumb|400px]]
= Introduction =

{{project_name_short}} 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. <ref>
[https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172 Fixing the Desktop Linux Security Model]
</ref> <ref>
[https://madaidans-insecurities.github.io/linux.html Linux (In)security]
</ref> These issues are [[Unspecific|unspecific]] to {{project_name_short}}. As such, {{project_name_short}} 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. [[Contribute|Contributions]] and [[Test|testers]] are most welcome.

= Future Enhancements =

== Principle of Least Privilege ==

Vulnerabilities in software are inevitable, therefore their impact must be contained by isolating processes. The {{project_name_short}} design has adopted the [https://en.wikipedia.org/wiki/Principle_of_least_privilege principle of least privilege] and [https://theinvisiblethings.blogspot.com/2008/09/three-approaches-to-computer-security.html security by isolation] 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 ([[Mobile_Operating_System_Comparison#iPhone_and_Android|issues with Android]]). In addition to locking down user space, this also protects the kernel because it restricts access to kernel interfaces like <code>/proc</code> or <code>/sys</code>, reducing the likelihood of kernel pointer and other leaks.

Furthermore, applications in the future will be executed inside <code>sandbox-app-launcher</code>. 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 <code>sandbox-app-launcher</code>, 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. <ref>
[https://source.android.com/docs/security/features/selinux Security-Enhanced Linux in Android]
</ref> <ref>
[https://source.android.com/security/app-sandbox Android: Application Sandbox]
</ref> <ref>
* YouTube: [https://www.youtube.com/watch?v=EkL1sDMXRVk Honey, I Shrunk the Attack Surface – Adventures in Android Security Hardening]
* PDF: [https://www.blackhat.com/docs/us-17/thursday/us-17-Kralevich-Honey-I-Shrunk-The-Attack-Surface-Adventures-In-Android-Security-Hardening.pdf Honey, I Shrunk the Attack Surface: Adventures in Android Security Hardening]
</ref>

Further reading:

* [[Apparmor-profile-everything]]
* [[Sandbox-app-launcher]]
* [https://github.com/roddhjav/apparmor.d GitHub: <code>apparmor.d</code>]
* [https://github.com/{{project_name_short}}/sandbox-app-launcher GitHub: <code>sandbox-app-launcher</code>]

== User Space Exploit Mitigations ==

Mitigating common classes of vulnerabilities and exploit techniques is also on the {{project_name_short}} security roadmap, but the possible mitigations are limited at present.

<code>sandbox-app-launcher</code> enforces a strict [https://en.wikipedia.org/wiki/W%5EX W^X ("write xor execute")] policy <ref><blockquote>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.</blockquote></ref> to prevent attackers from executing new arbitrary/malicious code. This will force attackers to utilize the already existing code -- for example [https://en.wikipedia.org/wiki/Return-oriented_programming Return-oriented programming (ROP)] / [https://security.stackexchange.com/questions/201196/concept-of-jump-oriented-programming-jop Jump-Oriented-Programming (JOP)] -- which is far more limiting and difficult to achieve. Unfortunately, some applications (mainly web browsers due to [https://en.wikipedia.org/wiki/Just-in-time_compilation just-in-time compilation (JIT)]) <ref><blockquote>...(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.</blockquote></ref> <ref>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.</ref> <ref>JIT leads to a faster browsing experience but opens up a large number of potential exploits, see: [https://www.securityweek.com/microsoft-launches-jit-free-super-duper-secure-mode-edge-browser-experiment Microsoft Launches JIT-Free 'Super Duper Secure Mode' Edge Browser Experiment].</ref> must be whitelisted. Currently, there is no protection for system services that run outside of <code>sandbox-app-launcher</code> — it is unclear how this could be implemented. {{project_name_short}} could possibly add its own <code>seccomp</code> wrapper, wait for [https://sara.smeso.it/en/latest/ S.A.R.A.], use systemd's <code>MemoryDenyWriteExecute</code>, or other measures.

Additional mitigations like [https://clang.llvm.org/docs/ControlFlowIntegrity.html CFI], [https://clang.llvm.org/docs/SafeStack.html SafeStack], [https://reviews.llvm.org/D54604 automatic stack variable initialization] and others are highly desirable but are unlikely to be utilized due to current project resourcing.

Further reading:
* [[Sandbox-app-launcher#Sandbox_Escape_Mitigation|Sandbox-app-launcher: Sandbox Escape Mitigation]]

== Kernel Hardening ==

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 {{project_name_short}} is developing <code>hardened-kernel</code> and <code>security-misc</code> 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.

{{project_name_short}} 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. <ref>[https://www.washingtonpost.com/sf/business/2015/11/05/net-of-insecurity-the-kernel-of-the-argument/ Net of insecurity: The kernel of the argument]</ref> <ref>https://grsecurity.net/~spender/interview_notes.txt</ref> <ref>[https://seclists.org/oss-sec/2017/q2/583 More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method]</ref> <ref>[https://grsecurity.net/10_years_of_linux_security.pdf 10 Years of Linux Security: A Report Card]</ref>

Further reading:
* [[Hardened-kernel]]
* [https://github.com/{{project_name_short}}/hardened-kernel GitHub: <code>hardened-kernel</code>]
* [https://github.com/anthraxx/linux-hardened GitHub: <code>linux-hardened</code>]

== Malware Persistence ==

If malware is capable of bypassing other protections, {{project_name_short}} 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 [https://www.kernel.org/doc/html/latest/admin-guide/device-mapper/verity.html <code>dm-verity</code>]. <ref><blockquote>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.</blockquote></ref> 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 <code>apparmor.d</code> and <code>sandbox-app-launcher</code>. 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 {{project_name_short}} project. Instead, users need to rely on solutions like [https://mjg59.dreamwidth.org/33981.html Intel Boot Guard] or [https://blog.cloudflare.com/anchoring-trust-a-hardware-secure-boot-story/ AMD Secure Boot] (different from UEFI Secure Boot) to verify the integrity of the firmware. Unfortunately these options are not very common.

{{project_name_short}} 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 <code>~/.bashrc</code>. However, this is not a strong defense and it will not defeat the efforts of an active adversary.

Further reading:
* [[Verified Boot]]
* [[Dev/VirusForget|VirusForget]]

== Additional Security Measures ==

* [[Security-misc#Remount_Secure|Remount Secure]]
* [[SUID Disabler and Permission Hardener]]
* [[Security-misc#Reduce_Kernel_Information_Leaks|Reduce Kernel Information Leaks]]
* [[Dev/boot modes|Multiple Boot Modes for Better Security (user, live, secureadmin, superadmin)]]

= Forum Discussion =

* [https://forums.whonix.org/t/whonix-security-roadmap/11381 Whonix Security Roadmap]

= See Also =

* [https://forums.whonix.org/t/fixing-the-desktop-linux-security-model/9172 Fixing the Desktop Linux Security Model]
* [[Dev/About_Computer_(In)Security|About Computer (In)Security]]
* [[Test|Testers for New Security Features Wanted!]]

= Footnotes =
{{reflist|close=1}}

{{Footer}}

[[Category:Development]]