Re: [PATCH] net: qrtr: Expand control port access to root

[Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>]

On 2/12/2026 12:07 AM, Stephen Smalley wrote:
> On Wed, Feb 11, 2026 at 12:20 PM Manivannan Sadhasivam <mani@kernel.org> wrote:
>> + SELinux folks
>>
>> 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:
>>>> When qrtr is loaded as module, qrtr-ns runs from SELinux kmod_t
>>>> 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.
>>> This really feels like a one-off hack, but it's far from my area
>>> of expertise.. Could you get an ack or review tag from some kernel
>>> maintainer working on security, capabilities or permissions?
>> I'm also not too sure about the problem because it looks like kmod_t has almost
>> near root privileges, but cannot do network administration.
>>
>> Maybe there is a valid reason for that?
> On Fedora, kmod_t is an unconfined domain and is allowed all capabilities.
> 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.
Thanks for the detailed suggestion, Stephen.

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.