Linux Security Summit North America 2025

The Linux Security Module (LSM) infrastructure has a limited ability to support multiple concurrent security policies. Expanding this capability to eventually encompass supporting arbitrary combination of modules is an ongoing activity. This talk will cover the current state of LSM stacking and the pending proposed changes. It will include a discussion of the limitations imposed when multiple modules have expectation on networking resources, how audit filtering is impacted and the implications for integrity. Opportunities for development of supporting features in parallel with the infrastructure changes will be presented.

TEE Device Interface Security Protocol (TDISP) is an industry standard that defines how to:
a) Establish trust between a Confidential VM (CVM) and a device, through attestation,
b) Secure the interconnect between the host and the device, and
c) Securely attach/detach a device interface to/from a CVM.

The main benefit of a CVM using a TDISP device vs a non-TDISP device is that the former is more performant, while still maintaining the confidentiality and integrity guarantees that Confidential Computing provides. Hence, TDISP plays a crucial part in making CVMs more performant, less expensive and, thus, easier to adopt.

An issue that currently exists with TDISP is that there is no standard way to prove that a TDISP attestation report and a platform attestation report originated from the same CVM. As a result, an attacker could replay an old TDISP attestation report with a CVM that doesn't have that TDISP device and cause a relying party to disclose secrets that wouldn't otherwise.

In this talk we would like to holistically explore this issue, the intended use cases and, finally, discuss a proposed solution using TPM NVIndex.

At present, SELinux only supports defining and enforcing a single system-wide security policy. As a result, for Linux containers, SELinux is generally only used to provide coarse-grained sandboxing and isolation of entire containers, and Linux distributions cannot effectively leverage SELinux from within a container. With the increasing trend toward containerized applications and cloud-native container workloads, there is a growing need for SELinux to better support containers. SELinux namespaces are a proposed feature enhancement that are intended to enable per-container security policies, i.e. each SELinux namespace can load its own policy, while remaining confined by its parent (and other ancestor) policies. SELinux namespaces bring benefits for Linux developers and users by enabling full use of SELinux within containers, whether or not the host OS uses SELinux itself. In this talk we present the background, design, implementation, performance, and residual challenges associated with the work to bring SELinux namespaces to the mainline Linux kernel.

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?

The popularity of fuzzing has led to its tight integration
into the software development process as a routine part
of the build and test, i.e., continuous fuzzing. This has
resulted in a substantial increase in the reporting of bugs
in open-source software, including the Linux kernel. To
keep up with the volume of bugs, it is crucial to automatically analyze the bugs to assist developers and maintain-
ers. Bug bisection, i.e., locating the commit that introduced a vulnerability, is one such analysis that can reveal
the range of affected software versions and help bug prioritization and patching. However, existing automated
solutions fall short in a number of ways: most of them either (1) directly run the same PoC on older software ver-
sions without adapting to changes in bug-triggering conditions and are prone to broken dynamic environments
or (2) require patches that may not be available when
the bug is discovered. In this work, we take a different approach to looking for evidence of fuzzer-exposed
vulnerabilities by looking for the underlying bug logic.
In this way, we can perform bug bisection much more
precisely and accurately.

This talk will present an empirical study of layered attestation for a cross-domain system. The presentation will overview how we boot the system into a trusted state and extend trust to a runtime.

Using IMA and TPM 2.0 we boot a verified attestation manager into a measured state where it may access its signing key. We prove the key can be used only if the right attestation system makes a request in a good state. Thus, a signature's presence on evidence strongly binds that evidence to the attestation manger.

Once booted, the attestation manger measures and appraises the cross-domain system according to a Copland attestation protocol. It calls LKIM and checks SELinux policy to ensure the underlying Linux system is in a good state. Then it measures CDS components and configurations for runtime appraisal.

We then discuss formal verification and empirical study of the attestation system. Specifically, why should trust the link from boot to runtime and the signing key's signature. We then discuss empirical studies that simulate various attacks illustrating design choices, assumptions and limitations.

Note: Co-authors are - Will Thomas, Logan Schmalz, Adam Petz and Sarah Scott

DNS remains a primary attack vector for data exfiltration and Command-and-Control (C2) operations, exploiting its inherent security flaws to bypass traditional defenses. This session presents a real-time, kernel-integrated security framework that actively prevents DNS-based data exfiltration using eBPF over Traffic Control (TC) scalable for large-scale distributed environments. Unlike passive detection approaches relying on anomalies, this solution dynamically intercepts DNS traffic at the kernel level, leveraging Deep Packet Inspection (DPI) and real-time lexical analysis to identify and block malicious requests before they leave the endpoint.

The framework also terminates C2 channels instantaneously, prevents DNS exfiltration over arbitrary transport ports, and dynamically blacklists domains across enterprise resolvers. With deep Linux kernel integration, it ensures minimal data loss, enhanced observability, and resilience against evolving threats. This session will explore the technical architecture, performance benchmarks, and deployment strategies to secure enterprise networks against modern DNS-based attacks.