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