[PATCH v2 2/2] LSM: Infrastructure management of the mnt_opts security blob
Casey Schaufler
casey at schaufler-ca.com
Tue Nov 4 17:46:07 UTC 2025
On 10/13/2025 1:55 PM, Paul Moore wrote:
> On Thu, Oct 9, 2025 at 2:38 PM Stephen Smalley
> <stephen.smalley.work at gmail.com> wrote:
>> On Thu, Sep 25, 2025 at 1:12 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>> Move management of the mnt_opts->security blob out of the individual
>>> security modules and into the security infrastructure. The modules
>>> tell the infrastructure how much space is required, and the space is
>>> allocated as required in the interfaces that use the blob.
>>>
>>> Signed-off-by: Casey Schaufler <casey at schaufler-ca.com>
>>> ---
>>> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
>>> index 4bba9d119713..1ccf880e4894 100644
>>> --- a/security/selinux/hooks.c
>>> +++ b/security/selinux/hooks.c
>>> @@ -656,19 +651,13 @@ static int selinux_set_mnt_opts(struct super_block *sb,
>>> mutex_lock(&sbsec->lock);
>>>
>>> if (!selinux_initialized()) {
>>> - if (!opts) {
>>> - /* Defer initialization until selinux_complete_init,
>>> - after the initial policy is loaded and the security
>>> - server is ready to handle calls. */
>>> - if (kern_flags & SECURITY_LSM_NATIVE_LABELS) {
>>> - sbsec->flags |= SE_SBNATIVE;
>>> - *set_kern_flags |= SECURITY_LSM_NATIVE_LABELS;
>>> - }
>>> - goto out;
>>> + /* Defer initialization until selinux_complete_init,
>>> + after the initial policy is loaded and the security
>>> + server is ready to handle calls. */
>>> + if (kern_flags & SECURITY_LSM_NATIVE_LABELS) {
>>> + sbsec->flags |= SE_SBNATIVE;
>>> + *set_kern_flags |= SECURITY_LSM_NATIVE_LABELS;
>> This seemingly would produce a change in behavior for SELinux.
Except that it doesn't, at least from the tests I've been able to find.
If multiple LSMs use mount options you can't use the !opts test, because
there may be options for another LSM. Deferring initialization is harmless
when there are options, as it's all checked again later.
>> Previously we would only do this if there were no SELinux mount
>> options specified.
> What Stephen said. I think this is good work that needs to be done
> (thank you for doing it!), but we have to preserve existing behaviors.
>
More information about the Linux-security-module-archive
mailing list