On Sun, Jan 26, 2025 at 10:30 PM <sergeh@xxxxxxxxxx> wrote:
>
> On Thu, Jan 02, 2025 at 11:44:30AM -0500, Stephen Smalley wrote:
> > The selinux netlink socket is used to notify userspace of changes to
> > the enforcing mode and policy reloads. At present, these notifications
> > are always sent to the initial network namespace. In order to support
> > multiple selinux namespaces, each with its own enforcing mode and
> > policy, we need to create and use a separate selinux netlink socket
> > for each network namespace.
> >
> > Without this change, a policy reload in a child selinux namespace
> > causes a notification to be sent to processes in the init namespace
> > with a sequence number that may be higher than the policy sequence
> > number for that namespace. As a result, userspace AVC instances in
> > the init namespace will then end up rejecting any further access
> > vector results from its own security server instance due to the
> > policy sequence number appearing to regress, which in turn causes
> > all subsequent uncached access checks to fail. Similarly,
> > without this change, changing enforcing mode in the child selinux
> > namespace triggers a notification to all userspace AVC instances
> > in the init namespace that will switch their enforcing modes.
> >
> > This change does alter SELinux behavior, since previously reloading
> > policy or changing enforcing mode in a non-init network namespace would
> > trigger a notification to processes in the init network namespace.
> > However, this behavior is not being relied upon by existing userspace
> > AFAICT and is arguably wrong regardless.
> >
> > This change presumes that one will always unshare the network namespace
> > when unsharing a new selinux namespace (the reverse is not required).
> > Otherwise, the same inconsistencies could arise between the notifications
> > and the relevant policy. At present, nothing enforces this guarantee
> > at the kernel level; it is left up to userspace (e.g. container runtimes).
> > It is an open question as to whether this is a good idea or whether
> > unsharing of the selinux namespace should automatically unshare the network
>
> Is there any advantage to not enforcing that? Something useful it might
> facilitate?
I'm not aware of any other namespace that triggers automatic unsharing
of a different namespace when it is unshared. Patch 32/44 ("selinux:
limit selinux netlink notifications to init namespace") also makes it
unnecessary to unshare the network namespace if you have no other
reason for doing so.
