issues about selinux namespace

[xiujianfeng]

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 at vger.kernel.org. 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 at huawei.com> 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.
> .