On Mon, Jul 19, 2021 at 9:55 AM xiujianfeng <xiujianfeng@xxxxxxxxxx> wrote: > > thanks stepthen, I've found James's patch in > https://lwn.net/Articles/737949/, > > but it seems can't resolve my questions, so any futher discussion would > be helpfull and welcome. > > 在 2021/7/14 20:11, Stephen Smalley 写道: > > Please take your email to the selinux@xxxxxxxxxxxxxxx. You are the > > second person to ask about selinux namespaces within the past week or > > so. I did upstream the refactoring and encapsulation of the data > > structures and code via the selinux_state patches, so those are in the > > mainline kernel these days, and Paul Moore and I have periodically > > re-based the remaining patches on top of upstream over in the > > https://github.com/SELinuxProject/selinux-kernel/tree/working-selinuxns > > branch. However, I had to drop the inode and superblock per-ns patches > > temporarily because of changes to LSM (inode blob management moved to > > the LSM framework out of the security modules), so that would need to > > be revisited. There was a separate patch from James Morris to support > > per-namespace security.selinux extended attributes; you can dig that > > out from the history or mailing lists if you want to revive that. I > > won't be able to look at it again until October at the earliest. > > > > On Wed, Jul 14, 2021 at 6:54 AM xiujianfeng <xiujianfeng@xxxxxxxxxx> wrote: > >> Hi Stephen, > >> > >> I am writing to discuss about selinux namespace because I found your > >> previous work on github and I think selinux namespace is helpful to > >> harden container security. So I try to do further work but there are > >> some issues mentioned in the commit message and I have no idea how to > >> fix them, it would be great if I can get help from you. > >> First is about selinux hook functions, we need to update each hook to > >> perform its processing on current namespace and all of its ancestors, > >> for object, we can have different sid/tag in different namespace based > >> on inode namespace support, but for task, do we need to maintain each > >> security context generated in the corresponding namespace? > >> Second is the lifecycle management of on-disk inode labels. it's not > >> easy to handle this, should we clean all corresponding labels on disk > >> when namespace exit? if we do this, it may cost long time to iterate > >> inode on disk and must relabel files when container restart, if not, the > >> inode xattr space maybe full and cannot write label again when new > >> namespace starts. > >> BTW, do you have plan to finish the work? > >> > >> I look forward to receiving your reply. > >> > >> Best wishes. I understand that many mail clients do not encourage inline/bottom replies, but when posting to the various Linux Kernel mailing lists please make the effort to reply inline, or at the bottom, as appropriate. Namespacing the SELinux kernel code is a rather tricky thing, both with respect to the design and the mechanics of the implementation. I don't think we have a concrete idea yet on how we want to proceed in all of the areas mentioned; designs - and implementations - have been offered, but I think we are missing someone to drive the topic forward with demonstrations, sample implementations, etc. It is never a bad idea to ask how you can help a project, but in this case I think the answer is to step back for a moment, describe your use-case/problem, explain how you envision a namespaced SELinux helping you resolve this, and finally how you would want the namespaced SELinux implementation to work (how would you interact with it both via policy and runtime management). On a personal note, the regular rebasing of the SELinux namespace work has suffered lately due to other time commitments at work. I have recently (today) started a new position which should allow me to dedicate much more of my working hours to upstream development; it may take me a couple of weeks to get settled in, but you can expect the regular rebasing of selinux/working-selinuxns to resume in the future. -- paul moore www.paul-moore.com
