LSM namespacing API

John Johansen john.johansen at canonical.com
Thu Aug 21 07:26:53 UTC 2025


On 8/19/25 11:58, Stephen Smalley wrote:
> On Tue, Aug 19, 2025 at 2:41 PM Paul Moore <paul at paul-moore.com> wrote:
>>
>> On Tue, Aug 19, 2025 at 1:11 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>
>>> The advantage of a clone flag is that the operation is atomic with
>>> the other namespace flag based behaviors. Having a two step process
>>>
>>>          clone(); lsm_set_self_attr(); - or -
>>>          lsm_set_self_attr(); clone();
>>>
>>> is going to lead to cases where neither order really works correctly.
>>
>> I was envisioning something that works similarly to LSM_ATTR_EXEC
>> where the unshare isn't immediate, but rather happens at a future
>> event.  With LSM_ATTR_EXEC it happens at the next exec*(), with
>> LSM_ATTR_UNSHARE I imagine it would happen at the next clone*().
> 
> I've only implemented support for an immediate unsharing of the
> SELinux namespace, not any kind of deferred unsharing until the next
> exec or clone.
> Not saying that would be impossible, but since I was following the
> example of clone(2) and unshare(2) I didn't do it.
> May be some complications in doing so, but I haven't looked at it yet.

if the hooks are setup correctly I expect it will actually remove some
potential complications. But I haven't deep dived the selinux code
yet so call that an uninformed hunch.




More information about the Linux-security-module-archive mailing list