Thread (3 messages) 3 messages, 3 authors, 2025-06-05

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.rst
diff --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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help