On Wed, Jul 20, 2022 at 5:42 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 7/19/2022 6:32 PM, Paul Moore wrote: > > On Fri, Jul 8, 2022 at 12:11 PM Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx> > >>>> 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
