Linux Security Summit North America 2025

The Linux Kernel Self-Protection Project was announced in 2015 as a way to gather folks doing security hardening work under a single umbrella and gain upstream traction for killing bug classes and eliminating exploitation methods. Linux security has made significant advances over the last decade as a result of the project's contributors.

We'll review the bug classes that have been completely eliminated (e.g. VLAs, setfs(), switch fall-through, stack variable zeroing), as well as bug classes that have gained wide mitigation coverage (e.g. refcount overflow, FORTIFY_SOURCE, allocation overflow, array overflow). We'll take a look at exploit blocking methods now in place (e.g. vmap stack, W^X, KASLR, slab hardening, %p hashing, IBT/BTI, SCS, KCFI), and newly available attack surface reduction (e.g. seccomp, __ro_after_init, lockdown).

What has the impact been after all this work? We'll review bug class frequency and severity to examine the trends. With so much of the low hanging fruit getting handled, we're now faced with trickier problems such as Use After Free flaws. We'll take a look at what's on the horizon to solve this and other kernel self-protection concerns.

A Play Machine is what is called a system with root as the guest account with only Apparmor to restrict access. It aims to demonstrate that necessary security can be provided by Apparmor without any Unix permissions and thus that root is not everything in modern security.

This play machine uses the apparmor.d project with the Full System Policies (FSP) mode enabled and enforced.
FSP is a special mode of apparmor.d that aims to provide profiles and user roles for every process and users and that ensure no unconfined process can run on the system.

In this talk, we will review the main challenges we encountered — including the security architecture of the profiles, testing, and profile integration. We will also discuss the complications involved in providing open root access on a VM to everyone.

The profiles, tooling, and documentation for the project have been published at https://github.com/roddhjav/apparmor.d. The play machine itself is available at https://play.pujol.io/

In recent years, security researchers and companies have looked to eBPF to build innovative security mechanisms with kernel independent bytecode and a soft guarantee of runtime safety. eBPF and the eBPF LSM in particular are especially useful in environments with bespoke security requirements where other LSMs cannot be or are not used, or kernel rebooting/recompilation is undesirable.
However, eBPF programs, but their nature, present a unique security challenge: any privileged process can fully manipulate the inner workings of all eBPF objects. While SELinux provides a level of coarse-grained access control over eBPF, it is difficult for eBPF developers to tailor SELinux policy to protect their individual tools.
This talk attempts to fill the gap by presenting an eBPF-based mandatory access control framework for protecting eBPF-based tools. The framework uses a configurable policy and no code change required for other tools to opt-in. We will present the design, implementation, and a policy example. We will also highlight areas for future work in the eBPF and LSM subsystems to provide more granular access controls.

Ubuntu 24.10 introduced permissions prompting as a an experimental feature to improve security and confidentiality for the Linux desktop. Traditionally Linux desktop applications have not been designed to be sandboxed and separated like android or iOS applications, making them difficult to isolate within the desktop environment. While applications written to support portals can be sandboxed within the modern desktop there are many applications that have not been updated to support them. This presentation will discuss and dive into what Ubuntu is doing to bring confinement and data confidentiality to traditional and legacy applications.

Kernel fuzzing has been traditionally done either via on-device fuzzing or using VMs and primarily targeting the attack surface exposed to user-space programs.
In this talk the authors introduce a novel approach towards fuzzing Linux kernel interfaces completely in user space without relying on hardware or virtualization solutions by leveraging an open-source project LKL (Linux kernel library). Using LKL it is possible to build Linux kernel as a user-space library and hook it with a coverage-guided engine such as libFuzzer to fuzz kernel interfaces. This approach enables us to create lightweight coverage-guided modular fuzzers targeting specific kernel interfaces. This approach provides such advantages as high fuzzing performance, scalability and ease of debugging crashes. One of the major highlights of this approach is the ability to target device-to-kernel interfaces exposed to the malicious peripheral devices which are difficult to cover using traditional fuzzing approaches. We will provide deep dive into LKL fuzzing details, like enabling ASAN for LKL, adding code coverage, and showcase examples of fuzzing USB HID and Android binder driver.

Incus is a project providing a private cloud platform that can be used by anyone from running on a simple laptop, Raspberry Pi to being run on thousands of servers in the datacenter.

The project began like most, making source code releases which found their way packaged in distros.

Over time, we developed tooling to automate deployment of those packages, allowing for more consistent deployments.
Unfortunately, this tooling still assumed quite a bit of familiarity with Linux distributions and configuration.

What we really wanted was a way to get reliable, identical deployments that could be used both by very large scale users running thousands of servers as well as by regular users at home who just want a working reliable virtualization platform.

This led to the development of Incus OS. A Debian based OS image made using systemd's mkosi, using a Secure Boot signed bootloader and Unified Kernel Image, TPM measurements throughout the boot process, an immutable OS image (using dm-verity) and full disk encryption for the data at rest based on TPM register state.

In this talk, we'll be diving into the design decisions behind Incus OS and look at its implementation.

This session is a short, open discussion on strategies and mechanisms for mitigating malicious modifications to structures in the data and bss segments as well as the heap of the kernel. We will overview case studies for how these attacks work across various types of CVEs, as well as existing protections, from those requiring new hardware (ARM MTE, TMDFI), to those working with existing hardware (ARM POE + kpkeys, HVCI/Heki-style enforcement systems), to software approaches (compiler-enforced data-flow, allocator restrictions, data layout randomization). We will then turn to an open discussion session of the benefits and drawbacks of offered protections, to (1) identify just how difficult we can make it for attackers using current mechanisms, (2) pinpoint precise gaps to focus in on for future work, and (3) come up with solutions to the harder problems involved, such as determining what is a "valid" write.

Refs.
https://lore.kernel.org/all/uqgb234tm4svoz2yvbamzal2srxnjnwrj2coiimvuz5bzblbia@pfabobbxo2jf/
https://lore.kernel.org/all/a32cjyekuecoowzbitc2xykilvpu6l3jjtityp7x5hw7xbiysp@5l2lptwmqiug/
https://www.usenix.org/system/files/usenixsecurity24-johannesmeyer.pdf

As confidential computing (CoCo) tech matures, integrating it into the cloud presents both technical challenges and opportunities. Specifically, the deployment of CoCo in a multi-tenant cloud infrastructure involves technical hurdles, such as remote boot and attestation, the impact on product aspects like provisioning time and live migration, tool compatibility, and constraints in fleet observability and debugging -- such as root cause analysis of guest kernel crashes (with customer permission).

In our previous presentation at LSS, we discussed the disconnect between CoCo efforts and the broader Linux kernel community. Since then, the desire to harden guest VMs against confidentiality threats has grown stronger, and a key question now is how to integrate CoCo into the cloud. Drawing from my professional experience, I’d like to spark and guide a discussion on the practical steps required to achieve this.