Re: [PATCH v2 0/4] Introduce security_create_user_ns()

[Paul Moore <paul@paul-moore.com>]

On Wed, Jul 20, 2022 at 5:42 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> On 7/19/2022 6:32 PM, Paul Moore wrote:
> > On Fri, Jul 8, 2022 at 12:11 PM Casey Schaufler <casey@schaufler-ca.com> wrote:
> >> On 7/8/2022 7:01 AM, Frederick Lawler wrote:
> >>> On 7/8/22 7:10 AM, Christian Göttsche wrote:
> >>>> ,On Fri, 8 Jul 2022 at 00:32, Frederick Lawler <fred@cloudflare.com>
> >>>> wrote:

...

> >>>> III.
> >>>>
> >>>> Maybe even attach a security context to namespaces so they can be
> >>>> further governed?
> >> That would likely add confusion to the existing security module namespace
> >> efforts. SELinux, Smack and AppArmor have all developed namespace models.
> >
> > I'm not sure I fully understand what Casey is saying here as SELinux
> > does not yet have an established namespace model to the best of my
> > understanding, but perhaps we are talking about different concepts for
> > the word "namespace"?
>
> Stephen Smalley proposed a SELinux namespace model, with patches,
> some time back. It hasn't been adopted, but I've seen at least one
> attempt to revive it. You're right that there isn't an established
> model.

If it isn't in the mainline kernel, it isn't an established namespace model.

I ported Stephen's initial namespace patches to new kernels for quite
some time, look at the working-selinuxns branch in the main SELinux
repository, but that doesn't mean they are ready for upstreaming.
Aside from some pretty critical implementation holes, there is the
much larger conceptual issue of how to deal with persistent filesystem
objects.  We've discussed that quite a bit among the SELinux
developers but have yet to arrive at a good-enough solution.  I have
some thoughts on how we might be able to make forward progress on
that, but it's wildly off-topic for this patchset discussion.  I
mostly wanted to make sure I was understanding what you were
referencing when you talked about a "SELinux namespace model", and it
is what I suspected ... which I believe is unrelated to the patches
being discussed here.

> >> That, or it could replace the various independent efforts with a single,
> >> unified security module namespace effort.
> >
> > We've talked about this before and I just don't see how that could
> > ever work, the LSM implementations are just too different to do
> > namespacing at the LSM layer.
>
> It's possible that fresh eyes might see options that those who have
> been staring at the current state and historical proposals may have
> missed.

That's always a possibility, and I'm definitely open to a clever
approach that would resolve all the current issues and not paint us
into a corner in the future, but I haven't seen anything close (or any
serious effort for that matter).

... and this still remains way off-topic for a discussion around
adding a hook to allow LSMs to enforce access controls on user
namespace creation.

> >   If a LSM is going to namespace
> > themselves, they need the ability to define what that means without
> > having to worry about what other LSMs want to do.
>
> Possibly. On the other hand, if someone came up with a rational scheme
> for general xattr namespacing I don't see that anyone would pass it up.

Oh geez ...

Namespacing xattrs is not the same thing as namespacing LSMs.  LSMs
may make use of xattrs, and namespacing xattrs may make it easier to
namespace a given LSM, but I'm not aware of an in-tree LSM that would
be magically namespaced if xattrs were namespaced.

This patchset has nothing to do with xattrs, it deals with adding a
LSM hook to implement LSM-based access controls for user namespace
creation.

-- 
paul-moore.com