PATCH 2/3] security: add Lilium - Linux Integrity Lock-In User Module - Documentation

[Paul Moore]

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