LSM namespacing API

[Casey Schaufler]

On 3/9/2026 11:15 AM, Stephen Smalley wrote:
> On Fri, Mar 6, 2026 at 4:01 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>> On 3/6/2026 9:48 AM, Dr. Greg wrote:
>>> On Tue, Mar 03, 2026 at 11:46:53AM -0500, Paul Moore wrote:
>>>
>>> Good morning, I hope the week is winding down well for everyone.
>>>
>>>> On Tue, Mar 3, 2026 at 8:30???AM Stephen Smalley
>>>>> I think my only caveat here is that your proposal is quite a bit more
>>>>> complex than what I implemented here:
>>>>> [1] https://lore.kernel.org/selinux/20251003190959.3288-2-stephen.smalley.work@gmail.com/
>>>>> [2] https://lore.kernel.org/selinux/20251003191328.3605-1-stephen.smalley.work@gmail.com/
>>>>> and I'm not sure the extra complexity is worth it.
>>>>>
>>>>> In particular:
>>>>> 1. Immediately unsharing the namespace upon lsm_set_self_attr() allows
>>>>> the caller to immediately and unambiguously know if the operation is
>>>>> supported and allowed ...
>>>> Performing the unshare operation immediately looks much less like a
>>>> LSM attribute and more like its own syscall.  That isn't a problem
>>>> in my eyes, it just means if this is the direction we want to go we
>>>> should implement a lsm_unshare(2) API, or something similar.
>>> Stephen's take on this is correct, the least complicated path forward
>>> is a simple call, presumably lsm_unshare(2), that instructs the LSM(s)
>>> to carry out whatever is needed to create a new security namespace.
>>>
>>> There are only two public implementations of what can be referred to
>>> as major security namespacing efforts; Stephen's work with SeLinux and
>>> our TSEM implementation.
>> Please be just a tiny bit careful before you make this sort of assertion:
>>
>>         https://lwn.net/Articles/645403/
> I believe both AppArmor and TOMOYO also have namespacing
> implementations already upstream, so SELinux is certainly not the only
> one. Looks like the Smack implementation you cited above was based on
> extending user namespaces rather than purely Smack-internal like the
> others; is that why it wasn't ultimately merged?

Less sophisticated solutions to the problem Smack namespaces were
intended to address became available. The effort stalled for lack of
a use case that required it. Much of what you want a namespace for
can be accomplished using process specific rules.