issues about selinux namespace

[xiujianfeng]

在 2021/7/20 10:56, Paul Moore 写道:
> On Mon, Jul 19, 2021 at 9:55 AM xiujianfeng <xiujianfeng at huawei.com> 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 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.
> 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).

thanks for you reply, I digged the history disscussion from 
https://marc.info/?l=selinux&m=150696042210126&w=2

and find one use-case: Running multiple android instances on a single 
host, this is the same as mine.

Anyway, I'll make a try.

>
> 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.
>