issues about selinux namespace
xiujianfeng at huawei.com
Wed Jul 21 13:12:36 UTC 2021
在 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
>> 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
>>> 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
> 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
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.
More information about the Linux-security-module-archive