On Wed, Jul 20, 2022 at 5:42 PM Casey Schaufler [off-list ref] wrote:

On 7/19/2022 6:32 PM, Paul Moore wrote:

quoted

On Fri, Jul 8, 2022 at 12:11 PM Casey Schaufler [off-list ref] wrote:

quoted

On 7/8/2022 7:01 AM, Frederick Lawler wrote:

quoted

On 7/8/22 7:10 AM, Christian Göttsche wrote:

quoted

,On Fri, 8 Jul 2022 at 00:32, Frederick Lawler [off-list ref]
wrote:

...

quoted

quoted

quoted

quoted

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.

quoted

quoted

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.

quoted

  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