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(-)
