Linux Security Summit North America 2025

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.

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.

Currently libseccomp can be used to build two categories of filters - an "allow" list and a "deny" list.

- In an allow list, the user specifies the syscalls to be allowed (read, write, etc.), and all other syscalls are denied by default
- In a deny list, the user specifies the syscalls that are deemed too powerful or dangerous and explicitly blocks them. All other syscalls are allowed by default

Both of these filters have a significant shortcoming when the system is updated to a newer kernel with new syscalls. Allow lists will block new syscalls, and this could lead to containers failing to run. Deny lists will allow new syscalls (even if they're dangerous) which could provide an attack vector for malicious applications.

We, the libseccomp developers, have proposed a solution for the above problem.
https://github.com/seccomp/libseccomp/pull/457

Our goal for this talk is a discussion between the libseccomp developers and the LSS audience. How are attendees solving this problem today? Does the proposed functionality and API meet their needs and offer a better solution? What other suggestions might the attendees have regarding kernel version based syscall filtering?