Re: SELinux namespaces re-base

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

 



On Thu, Sep 26, 2024 at 1:16 PM Stephen Smalley
<stephen.smalley.work@xxxxxxxxx> wrote:
>
> On Thu, Sep 26, 2024 at 9:14 AM Stephen Smalley
> <stephen.smalley.work@xxxxxxxxx> wrote:
> > As I've been converting the permission checks to use namespace-aware
> > helpers, I've noted policy capabilities (as in network_peer_controls,
> > open_perms, extended_socket_class, always_check_network, etc) as a
> > case that isn't cleanly handled by my current approach. At present,
> > the hook functions are just checking the value of the policy
> > capability in the current SELinux namespace to decide which branch of
> > the hook function to follow, and then within whichever branch is
> > selected, each permission check that is converted to using
> > namespace-aware helpers is checking permissions against the current
> > and all ancestor namespaces.
> >
> > So for example, if the current namespace enables open permission, then
> > it will check open permission against the current namespace and all
> > ancestors, irrespective of whether the ancestor enabled that
> > capability or not. Similarly, if the current namespace disables open
> > permission, then it will NOT check open permission against any
> > namespaces, even if the ancestors enabled it.
> >
> > Lifting the logic to iterate through all of the namespaces up into
> > each hook function is possible but rather painful. That said, it may
> > be unavoidable if we want to support different policy capability
> > settings between child namespaces and their ancestors, or prevent
> > child namespaces from effectively disabling certain checks by
> > disabling those capabilities.
> >
> > If I were to go down that route, then I would also need to resolve how
> > to handle the non-permission checking logic in each hook across
> > multiple namespaces, e.g. labeling logic. Currently it is just
> > assigning SIDs/contexts to objects based on the current namespace,
> > then checking permissions against all namespaces with that
> > SID/context. But if each hook function has its body wrapped with the
> > same loop that currently exists inside the namespace-aware permission
> > checking functions to iterate through the namespaces, then we would
> > actually end up with multiple SIDs/contexts computed and need to
> > decide which one to use (or special case that part of the body to skip
> > doing so for anything but the first/current namespace).
> >
> > Thoughts?
>
> On 2nd thought, for hooks that don't depend on policy capabilities, I
> think the current approach is fine, and works for the majority of the
> hooks.
>
> For the subset of hooks that depend on policy capabilities, I will
> lift the logic where needed to ensure that we apply the right checks
> in each namespace based on that namespace's enabled policy
> capabilities.
>
> Labeling logic will still be based on the current SELinux namespace at
> the point where the kernel object is first created/instantiated, but
> permissions to that label will be checked in the current and ancestor
> namespaces. There are some potential gotchas there, e.g. a child
> namespace could load a policy that labels all objects it
> creates/instantiates with a context to which it has access, even
> overriding file xattrs by specifying something other than fs_use_xattr
> in its policy for the filesystem type.
>
> Some of the policy capabilities have effects other than changing which
> permissions are checked, e.g. extended_socket_class alters what
> security class is set in the security blob and later used in
> permission checks, so if a socket is created with that disabled in one
> namespace and accessed in another namespace, the permission checks
> might not be on the "correct" security class for the other namespace.
> Other policy capabilities affect labeling, e.g. cgroup_seclabel,
> genfs_seclabel_symlinks, userspace_initial_context, which likewise
> could lead to an object created and labeled in one namespace
> triggering permission checks against the "wrong" label if accessed in
> another namespace.

Since an increasing number of the testsuite tests are failing in a
child SELinux namespace due to even unconfined_t in the parent
namespace not being allowed the requisite permissions in the parent
namespace, I've created a modified version of the testsuite policy to
allow those permissions to unconfined_t and also disabled the tests
that cannot work currently due to the separate network namespace.
Those changes are on a branch of my fork of the selinux-testsuite at:
https://github.com/stephensmalley/selinux-testsuite/tree/selinuxns

With those changes, if I load the test policy into the parent
namespace (so that the test domains/types are defined and access is
allowed to unconfined_t) and then create a child namespace from an
unconfined_t shell and run the testsuite from it, all of the
(still-enabled) tests pass. I'll keep amending the test policy on that
branch with further changes as I convert additional permission checks
to be namespace-aware. Eventually we can figure out if it makes sense
to merge these into the main testsuite but that can wait until we're
ready to merge the kernel namespace support itself.





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

  Powered by Linux