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

[Simon Thoby <git@nightmared.fr>]

On 5/30/25 01:49, Paul Moore wrote:
> On Thu, May 22, 2025 at 5:23 AM Simon Thoby <git@nightmared.fr> wrote:
>> On 5/21/25 23:31, Paul Moore wrote:
>>> On Wed, May 21, 2025 at 10:03 AM Simon THOBY <git@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@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!
> 
> Please don't feel bad about it, often simply doing "something" is what
> makes things happen, even if that original "something" turns out not
> to be the final "thing" :)
> 
>> 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.
> 
> My thinking around possible augmentation of LoadPin is that both
> LoadPin and Loadpol share a similar, limited focus of controlling
> access to kernel module loading and Loadpol has support for a basic
> loadable policy, a policy that could likely be extended to support a
> LoadPin-esque construct that limit module loading based on filesystem
> pinning.  It probably makes more sense to think of adding LoadPin
> support to Loadpol, rather than augmenting LoadPin to support the
> Loadpol concepts, but for consistency with upstream we probably need
> to speak in terms of the latter.
> 
Thanks for the reply, I now see what you meant. I will try to put something
together (hopefully next week), starting with looking at how we can express
the current LoadPin feature set as a loadable and user-extensible policy, and
then add non-filesystem-related policy entries (like module name restrictions)
to that policy.