Re: PATCH 2/3] security: add Lilium - Linux Integrity Lock-In User Module - Documentation
From: Paul Moore <paul@paul-moore.com>
Date: 2025-06-05 00:22:35
Also in:
linux-doc, lkml
On Sat, May 31, 2025 at 9:07 PM ℰ𝓃𝓏ℴ ℱ𝓊𝓀ℯ [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From 23d323f793b888bb2ad0d2a7a1ca095d5d64d0b8 Mon Sep 17 00:00:00 2001 From: Enzo Fuke <redacted> Date: Sun, 1 Jun 2025 00:11:36 +0000 Subject: [PATCH] Lilium Documentation --- Documentation/security/lilium.rst | 402 ++++++++++++++++++++++++++++++ 1 file changed, 402 insertions(+) create mode 100644 Documentation/security/lilium.rstdiff --git a/Documentation/security/lilium.rst b/Documentation/security/lilium.rst new file mode 100644 index 0000000..bd25ff6 --- /dev/null +++ b/Documentation/security/lilium.rst@@ -0,0 +1,402 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +============================================== +Lilium (Linux Integrity Lock-In User Module) +============================================== + +:Author: Enzo Fuke +:Date: May 2025 +:Version: 1.0 + +Introduction +============ + +Lilium (Linux Integrity Lock-In User Module) is a Linux Security Module (LSM) +designed to enhance system security by providing fine-grained control over +critical system operations. It implements a modular approach to security, +allowing administrators to selectively enable specific security mechanisms +based on their requirements. + +The name "Lilium" is an acronym for "Linux Integrity Lock-In User Module", +reflecting its purpose of locking down various system operations to maintain +system integrity and security. + +Security Philosophy +------------------ + +Lilium follows the principle of "secure by default but configurable". All +security mechanisms are disabled by default to ensure compatibility with +existing systems, but can be easily enabled individually through the sysfs +interface. This approach allows administrators to gradually implement security +measures without disrupting system functionality. + +The module is designed with the following principles in mind: + +1. **Modularity**: Each security mechanism can be enabled independently. +2. **Contextual Logic**: Security decisions consider the context of operations. +3. **Least Privilege**: Restrictions follow the principle of least privilege. +4. **Compatibility**: Works alongside other LSMs in the Linux security stack. + +Features +======== + +Lilium provides the following security mechanisms, each addressing specific +security concerns: + +1. **ptrace restrictions** + + Controls which processes can trace other processes using the ptrace system + call. This helps prevent unauthorized debugging and memory inspection of + running processes, which could be used to extract sensitive information or + modify process behavior. + + When enabled, only processes with CAP_SYS_PTRACE capability can attach to + other processes using ptrace, preventing unprivileged users from debugging + or inspecting other users' processes.
I agree with all of the other feedback you've received, but I'm also concerned that there isn't a common security concept tying all of these access controls together; they are all standalone controls that can be toggled on/off either at build or runtime. While we don't necessarily require a full, formal security model for new LSMs, if you have some reasoning as to why this collection of capability-based access controls belong together in a LSM it would be good to share that. Even with a better explanation, and some agreement that it is reasonable, it seems like these checks might be better suited as Yama enhancements rather than a new LSM. -- paul-moore.com