Re: [PATCH] net: qrtr: Expand control port access to root
From: Vishnu Santhosh
Date: Wed Feb 18 2026 - 04:17:48 EST
On 2/12/2026 12:07 AM, Stephen Smalley wrote:
On Wed, Feb 11, 2026 at 12:20 PM Manivannan Sadhasivam <mani@xxxxxxxxxx> wrote:Thanks for the detailed suggestion, Stephen.
+ SELinux folksOn Fedora, kmod_t is an unconfined domain and is allowed all capabilities.
On Fri, Feb 06, 2026 at 06:36:57PM -0800, Jakub Kicinski wrote:
On Thu, 05 Feb 2026 13:51:31 +0530 Vishnu Santhosh wrote:I'm also not too sure about the problem because it looks like kmod_t has almost
When qrtr is loaded as module, qrtr-ns runs from SELinux kmod_tThis really feels like a one-off hack, but it's far from my area
domain. On targets using upstream SELinux policies, this domain
does not receive CAP_NET_ADMIN, which prevents it from binding
control port even though qrtr-ns is a trusted system component.
Granting kmod_t the CAP_NET_ADMIN capability in policy is possible,
but not desirable, as kmod_t is not expected to perform networking
operations and widening its capability set is discouraged.
To address this in a contained way within qrtr, extend the control
port permission check to allow binding when either:
- the process has CAP_NET_ADMIN, or
- the process belongs to GLOBAL_ROOT_GID (root-equivalent tasks)
This permits qrtr-ns to successfully bind its control port in
kmod_t restricted environments without broadening SELinux capability
assignments.
of expertise.. Could you get an ack or review tag from some kernel
maintainer working on security, capabilities or permissions?
near root privileges, but cannot do network administration.
Maybe there is a valid reason for that?
Upstream refpolicy likely hasn't encountered a need for net_admin
during module initialization previously and thus doesn't allow it just
as a matter of least privilege.
Since you referenced kmod_t, I assume this is just for Linux, not
Android (which has an entirely different policy).
I would fix this in policy rather than changing the kernel module code.
To address the QRTR NS initialization failure, I initially tested the
following change in our downstream policy (modutils.te):
allow kmod_t self:capability net_admin;
Since the kmod_t domain is only used for module insertion via
insmod/modprobe and does not perform networking operations, our SELinux
team were initially hesitant to pick up this change. Based on that
internal feedback, I made this change in QRTR NS.
After your comment, it is clear that the correct resolution is to adjust
the SELinux policy rather than modifying the kernel module.
Our SELinux team (CC’d Ravi and Sasi) agreed to submit a separate patch to
extend kmod_t with net_admin in the upstream refpolicy so that the module can
initialize correctly without kernel driver changes.