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

[Paul Moore]

On Thu, May 22, 2025 at 5:23 AM Simon Thoby <git at nightmared.fr> wrote:
> 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!

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.

> 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.

Of course, the combination, or not, of LoadPin and Loadpol is really
up to the two of you.

> 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.

I think LoadPin is the obvious choice.

-- 
paul-moore.com