LSM namespacing API
Stephen Smalley
stephen.smalley.work at gmail.com
Tue Aug 19 18:58:16 UTC 2025
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.
More information about the Linux-security-module-archive
mailing list