Kicksecure ™ Security Roadmap
Kicksecure ™ 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.   These issues are unspecific to Kicksecure ™. As such, Kicksecure ™ 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.
Principle of Least Privilege
Vulnerabilities in software are inevitable, therefore their impact must be contained by isolating processes. The Kicksecure ™ design has adopted the principle of least privilege and 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 (issues with Android). In addition to locking down user space, this also protects the kernel because it restricts access to kernel interfaces like
/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.   
User Space Exploit Mitigations
Mitigating common classes of vulnerabilities and exploit techniques is also on the Kicksecure ™ 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.
sandbox-app-launcher enforces a strict W^X ("write xor execute") policy  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) / Jump-Oriented-Programming (JOP) -- which is far more limiting and difficult to achieve. Unfortunately, some applications (mainly web browsers due to just-in-time compilation (JIT))    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. Kicksecure ™ could possibly add its own
seccomp wrapper, wait for S.A.R.A., use systemd's
MemoryDenyWriteExecute, or other measures.
- Sandbox-app-launcher: Sandbox Escape Mitigation
- Hardened Malloc Kicksecure
- GitHub: GrapheneOS/hardened_malloc
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 Kicksecure ™ is developing
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.
Kicksecure ™ 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.    
If malware is capable of bypassing other protections, Kicksecure ™ 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.  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
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 Kicksecure ™ project. Instead, users need to rely on solutions like Intel Boot Guard or AMD Secure Boot (different from UEFI Secure Boot) to verify the integrity of the firmware. Unfortunately these options are not very common.
Kicksecure ™ 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.
Additional Security Measures
- 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
- About Computer (In)Security
- Testers for New Security Features Wanted!
- Fixing the Desktop Linux Security Model
- Linux (In)security
- Security-Enhanced Linux in Android
- Android: Application Sandbox
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.
- Net of insecurity: The kernel of the argument
- More CONFIG_VMAP_STACK vulnerabilities, refcount_t UAF, and an ignored Secure Boot bypass / rootkit method
- 10 Years of Linux Security: A Report Card
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.