Hi, On July 24, Jann Horn reported [1] a security issue in Landlock [2]. He provided a fix and a proof of concept. Many thanks for all this work! He discovered a logical bug that makes it possible for a process to escape its sandbox and bypass any Landlock restrictions. This is due to a missing LSM hook implementation for the special case of keyctl(2)'s KEYCTL_SESSION_TO_PARENT. This issue is now identified as CVE-2024-42318 [2].
[1] https://bugs.chromium.org/p/project-zero/issues/detail?id=2566 [2] https://landlock.io/ [3] https://cve.org/CVERecord/?id=CVE-2024-42318 The issue was fixed a few hours later [4] and we developed a dedicated test [5] to make sure the fix works as expected and that the issue never happens again. This was merged in Linux 6.11-rc1 [6] published July 28. [4] https://git.kernel.org/torvalds/c/39705a6c29f8a2b93cf5b99528a55366c50014d1 [5] https://git.kernel.org/torvalds/c/cc374782b6ca0fd634482391da977542443d3368 [6] https://git.kernel.org/torvalds/c/86b405ad8d0d2994a7ffbacb8fcf83be8afb952c The fix has also been backported to: - Linux 6.10.3 (released on August 3) - Linux 6.6.44 (released on August 3) - Linux 6.1.103 (released on August 3) - Linux 5.15.165 (will be released in a few days, but in the meantime you can cherry-pick https://git.kernel.org/stable/c/0d74fd54db0bd0c0c224bef0da8fc95ea9c9f36c) This vulnerability only impacts sandboxing put in place by Landlock, but the kernel is not at risk, nor system services. The impact is limited thanks to the stackable LSM infrastructure. To fix this vulnerability, only the kernel needs to be updated, not the sandboxed programs which will automatically be well-sandboxed with an up-to-date kernel. Sandboxing with Landlock is really an investment to leverage current and future Landlock features. To exploit this vulnerability, an attacker needs to have full code execution including the ability to perform arbitrary syscalls, especially keyctl(2). Complementary security mechanisms can be put in place to avoid arbitrary code execution or arbitrary syscalls (e.g. with seccomp filters). To test the fix, here are simple steps to run on an up-to-date kernel source tree (Linux 6.6.44 to run these tests with an unprivileged user): make alldefconfig make TARGETS=landlock kselftest-install ./tools/testing/selftests/kselftest_install/landlock/base_test # The global.cred_transfer test should pass. Landlock is a defense-in-depth security mechanism. Even if it is already useful to protect users and applications, it should not be the only security layer for the system, mainly because it is not a full feature access control system yet. As explained in the documentation [7], some actions may not be restricted yet, which may also be the case for other security modules. We are working to extend the access control types [8], but it takes time and resources to build a new unprivileged access control system properly handling Linux specificities. [7] https://docs.kernel.org/userspace-api/landlock.html#filesystem-flags [8] https://github.com/orgs/landlock-lsm/projects/1 Looking at the other side, it is interesting to note that Landlock can also limit the impact of similar potential vulnerabilities affecting other access control systems. This issue also started a discussion to improve (or remove) the KEYCTL_SESSION_TO_PARENT special case [9]. [9] https://lore.kernel.org/r/20240805-remove-cred-transfer-v2-0-a2aa1d45e...@google.com We are two official reviewers for Landlock, but contributors and other reviewers such as Jann (who previously reviewed the initial Landlock code) also work on making changes as safe and secure as possible. The Linux kernel needs more eyes, time, and experts to proactively find these kind of issues. If you are interested, reward programs [10] may help. [10] https://alpha-omega.dev/ Regards, Mickaël
