在 2021/7/20 10:56, Paul Moore 写道:
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).
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.
