[PATCH] lsm: make SECURITY_PATH always enabled

[Paul Moore]

On Wed, Apr 23, 2025 at 4:54 PM Song Liu <songliubraving at meta.com> wrote:
> > On Apr 23, 2025, at 7:58 AM, Paul Moore <paul at paul-moore.com> wrote:
>
> [...]
>
> >>> Without putting much thought into what would fall under
> >>> CONFIG_SECURITY_INODE, I think it would be interesting to see what
> >>> hooks one might be able to make conditional on such a Kconfig knob.
> >>> Using security_inode_permission() as a simple test, it looks like only
> >>> SELinux and Smack provide implementations, spot checks on a few other
> >>> security_*inode*() hooks shows similar, or even more limited, results.
> >>>
> >>> You would need to spend some time to determine what LSM hooks are used
> >>> by which LSMs and adjust their Kconfigs appropriately for the new
> >>> CONFIG_SECURITY_INODE knob, but if you do that then I think that would
> >>> be okay.
> >>
> >> Well, I was hoping to simplify the CONFIGs by removing one. So I am
> >> not sure whether adding a new CONFIG is the right thing to do.
> >
> > Ah, in that case I suspect you're going to be disappointed as I'm
> > fairly confident we don't want to consolidate the inode and path based
> > hooks under one Kconfig knob at this point in time.  If anything, I
> > think there may be some value in adding an inode Kconfig as described
> > above, which I realize isn't your original goal, but still ... :)
>
> I am thinking whether it is possible to have each LSM selects required
> hooks, and only enable those at compile time. OTOH, my primary focus is
> BPF LSM, so these optimizations matter little for my use cases.

Ignoring for a moment just how awkward it would be to have a Kconfig
value for each LSM, it is important to remember that LSMs are still
selectable at system boot (assuming they have been built into the
kernel), so there will always be the potential for "empty" LSM hooks
on any given system boot.

Like I said before, I'm open to someone exploring the addition of new
LSM Kconfig knobs to provide greater granularity about which hooks are
enabled at build time, however, these new knobs will both need to make
sense from a logical grouping perspective as well as have a meaningful
impact on the enabled hooks across the current in-tree LSMs.

-- 
paul-moore.com