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