On Sat, May 31, 2025 at 9:07 PM ℰ𝓃𝓏ℴ ℱ𝓊𝓀ℯ <milesonerd@xxxxxxxxxxx> wrote: > > From 23d323f793b888bb2ad0d2a7a1ca095d5d64d0b8 Mon Sep 17 00:00:00 2001 > From: Enzo Fuke <milesonerd@xxxxxxxxxxx> > 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
