Re: [RFC PATCH 05/44] netstate,selinux: create the selinux netlink socket per network namespace

[sergeh@kernel.org]

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?