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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux