On 5/30/25 01:49, Paul Moore wrote: > On Thu, May 22, 2025 at 5:23 AM Simon Thoby <git@xxxxxxxxxxxxx> wrote: >> On 5/21/25 23:31, Paul Moore wrote: >>> On Wed, May 21, 2025 at 10:03 AM Simon THOBY <git@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> >>>> --- >>>> 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.
