| Message ID | 20220216125206.20975-1-igor.baranov@huawei.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | SELinux-namespaces | expand |
On 2/16/2022 4:52 AM, Igor Baranov wrote: > Hi all! > Our team at Huawei decided to revive the work on SELinux namespaces. > We took https://github.com/stephensmalley/selinux-kernel/tree/working-selinuxns > as a basis with some patches from selinuxns-xattr. > We reworked them significantly, fixing and adding functionality. > As a result we managed to run a CentOS Docker container with SELinux in enforcing mode! > > We would like to start our discussion with the smallest, but most basic > change: we gave each namespace a unique identifier. > It is assigned to a namespace from the global counter > that is incremented each time you create it. > > All the objects which in the original patchset kept a pointer to their > namespace now store its identifier. It's needed only to determine whether > an object belongs to our (in the current context) namespace or not. > The aim of this change is to reduce the height of the Babel tower of pointers, > because in the original patch there was such a mess and such bugs, > that we decided to cut this Gordian knot, removing some pointers altogether. > > This is a very small part of our changes, but we see the point of discussing > more when we come to this. > > Particularly because there are alternative approaches, > such as Casey Schaufler's suggestion, which is mentioned > in http://namei.org/presentations/selinux_namespacing_lca2018.pdf > "How to deal with secids (32-bit IDs) which are passed to core kernel and > cached there - Make them global" which seems quite promising for us too. The promise of secids is that they are opaque identifiers and thus only need to be meaningful to the policy engine. > In the case of this approach, it is not necessary to store the namespace ID > in objects, because it can be deduced from sid. But a detailed study of > this area reveals some painful challenges. For example: fragmentation of > the global sid space when loading/unloading different policies. And the > depth of the rabbit hole is not obvious from current positions. This is a > separate big topic. The downside of secids is that eventually you do need to map them to something meaningful to the policy engine. This is why I have always (since 1986) objected to them. The SELinux implementation would be much simpler without them. (I'm ignoring the networking implications for the moment. :) ). Nonetheless, with separate AVC instances the mapping should be (I've been told) straight forward. > > Igor Baranov (1): > Replace state pointer with namespace id > > security/selinux/hooks.c | 29 ++++++++++++++++++++++++----- > security/selinux/include/objsec.h | 4 +++- > security/selinux/include/security.h | 2 ++ > 3 files changed, 29 insertions(+), 6 deletions(-) >
On Wed, Feb 16, 2022 at 7:52 AM Igor Baranov <igor.baranov@huawei.com> wrote: > > Hi all! > Our team at Huawei decided to revive the work on SELinux namespaces. > We took https://github.com/stephensmalley/selinux-kernel/tree/working-selinuxns > as a basis with some patches from selinuxns-xattr. Hello! For reference there is a *slightly* more recent forward port of those patches in the main SELinux repo under the working-selinuxns branch. I haven't forward ported those patches since v5.10-rc1 as there are some rather significant technical hurdles around persistent object labeling which I don't believe have been adequately resolved yet. The prefixed/namespaces xattr approach that you mention above may work for a limited number of namespaces, but I worry there is a scalability issue that needs to be resolved; we can't simply keep adding xattrs to inodes. * https://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux.git Also, are there rest of your patches online anywhere? Patch 1/1 isn't very interesting on its own.