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

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

Also I think the naming scheme is <object>_<verb>.

That's a good call out. I was originally hoping to keep the
security_*() match with the hook name matched with the caller function
to keep things all aligned. If no one objects to renaming the hook, I
can rename the hook for v3.

No objection from me.

[Sorry for the delay, the last week or two has been pretty busy.]

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. The model proposed for Smack wasn't adopted either. My point
is that models have been developed and refinements and/or alternatives
are likely to be suggested.

quoted

From a SELinux perspective, if we are going to control access to a

namespace beyond simple creation, we would need to assign the
namespace a label (inherited from the creating process).  Although
that would need some discussion among the SELinux folks as this would
mean treating a userns as a proper system entity from a policy
perspective which is ... interesting.

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.

  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.