[RFC PATCH 9/9] Loadpol LSM: add a minimal documentation

[Simon Thoby]

On 5/21/25 23:31, Paul Moore wrote:
> On Wed, May 21, 2025 at 10:03 AM Simon THOBY <git at nightmared.fr> wrote:
>>
>> Introduce a minimal documentation for Loadpol, presenting the policy
>> format and the two user interfaces: the securityfs policy file and the
>> sysctl.
>>
>> Signed-off-by: Simon THOBY <git at nightmared.fr>
>> ---
>>  Documentation/admin-guide/LSM/Loadpol.rst | 81 +++++++++++++++++++++++
>>  Documentation/admin-guide/LSM/index.rst   |  1 +
>>  2 files changed, 82 insertions(+)
>>  create mode 100644 Documentation/admin-guide/LSM/Loadpol.rst
>>
>> diff --git a/Documentation/admin-guide/LSM/Loadpol.rst b/Documentation/admin-guide/LSM/Loadpol.rst
>> new file mode 100644
>> index 000000000000..0aa24a8d393c
>> --- /dev/null
>> +++ b/Documentation/admin-guide/LSM/Loadpol.rst
>> @@ -0,0 +1,81 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +=======
>> +Loadpol
>> +=======
>> +
>> +Loadpol is a Linux Security Module that enforces a user-provided policy
>> +when decided whether a dynamic module can be loaded or not.
> 
> Considering the relatively small scope of Loadpol, I have to ask if
> you've considered augmenting other LSMs to meet your needs?  While
> LoadPin is different from what you are proposing here, it does
> similarly limit its scope to kernel module load operations, and given
> the current simplicity of LoadPin I imagine one could find a creative
> way to extend it to support what you are trying to do.
> 

I indeed felt a bit ridiculous introducing a new LSM for a limited feature
like that!
What's more, I don't see it being extended much in the future - we could
always imagine things like signed policy updates, but other than that it's
probably "feature-complete", as the feature itself is fairly small.
The difficulty with LoadPin is that it rely relies on the notion of
filesystem (which is coupled with the origin of the kernel modules) to ensure
that modules are valid. On a general-purpose distributions, the modules
would be stored on the same (non-integrity-verified) filesystem, so
segregating the modules by filesystem is not really possible there.
Extending LoadPin to provide the same features is probably possible, but I
fear this would add complexity to loading by trying to make it do two
slightly different jobs at once.

CC-ing Kees Cook as he is the maintainer of the LoadPin module, he may have
opinions on what features may or may not fit inside LoadPin.

As for other LSMs, I don't really see one that tries to provide similar
features, but I someone is open to extending an existing LSM for that, I
would be happy to help.

To stop the proliferation of LSMs (if this proves to be a problem),
I could see a "miscellaneous" one that groups the tiny LSMs (which each
feature set hidden behind a configuration option), like loadpin, yama,
safesetid, and future feature sets like loadpol.


>> +The policy can be read and rewritten at ``/sys/kernel/security/loadpol/policy``.
>> +
>> +A default policy is created that contains the current list of blacklisted modules,
>> +and a catch-all entry that allow loading any module.
>> +
>> +Policy format
>> +=============
>> +
>> +The policy is defined as a set of line-separated entries.
>> +Each entry define the conditions for a match (the origin of the load request and
>> +the name of the kernel module), and the action to take when the load request
>> +matches the entry.
>> +
>> +
>> +Entry syntax: ``[origin=(userspace|kernel|kernel,userspace)] [module=<module_name>] action=(allow|deny)``
>> +
>> +There are two matching conditions:
>> +
>> +``origin``:
>> +    Load Requests can come from two origins:
>> +
>> +    * ``userspace`` (ie. a program in userspace called modprobe/insmod)
>> +    * ``kernel`` (the kernel requested the module directly by calling
>> +      ``request_module(...)``, e.g. loading a filesystem when performing a
>> +      ``-o loop`` mount).
>> +
>> +    When unspecified, the condition defaults to ``kernel,userspace`` (which means
>> +    that both origins match).
>> +
>> +``module``:
>> +    Name of the kernel module being matched. The name can contain wilcards.
>> +    Beware, module aliases do not work!
> 
> It would be good to have a section in the documentation where you
> discuss how the risks inherent to filtering on the module name, and
> approaches that can be used to ensure that a malicious module is not
> simply "borrowing" a known good module's name.
> 
I understand the concern, but the idea of the LSM is not to substitute itself
to existing security mechanisms (as you know, it technically couldn't anyway, LSM
being all about stacking additional layers).
So we still rely on kernel module signing. To forge a malicious module with a valid
name, one would have to have access to the signing key. If that happens, I consider
the game to be over, as they can forge arbitrary kernel modules.
In most practical cases, I think people will trust two keys:
- the distributor key, built in the kernel
- User-supplied keys, distributed via MOK (or in the UEFI KEK maybe?)
Most modules would be signed with the distributor key, with security software
(or custom kernel drivers) being signed with the user key (hopefully off-system,
so that the end-users systems do not contain the signing key, otherwise this
defeats the whole point of signing).
All modules would still be signed, and we should be safe from a module lying about
its name (naming conflicts notwithstanding, but this shouldn't happen anyway).
But I could have an explanation in the documentation about that!