Re: [RFC PATCH 0/1] SELinux-namespaces

From: Casey Schaufler <casey@schaufler-ca.com>
To: Igor Baranov <igor.baranov@huawei.com>, paul@paul-moore.com
Cc: hw.likun@huawei.com, jamorris@linux.microsoft.com,
	linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
	stephen.smalley.work@gmail.com, xiujianfeng@huawei.com,
	alexander.kozhevnikov@huawei.com, yusongping@huawei.com,
	artem.kuzin@huawei.com, Casey Schaufler <casey@schaufler-ca.com>
Subject: Re: [RFC PATCH 0/1] SELinux-namespaces
Date: Wed, 16 Feb 2022 09:08:23 -0800	[thread overview]
Message-ID: <8e752954-d871-c67e-32b2-b1293753bf07@schaufler-ca.com> (raw)
In-Reply-To: <20220216125206.20975-1-igor.baranov@huawei.com>

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