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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260206183657.0477e50a@kernel.org>
Date: Fri, 6 Feb 2026 18:36:57 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Vishnu Santhosh <vishnu.santhosh@....qualcomm.com>
Cc: Manivannan Sadhasivam <mani@...nel.org>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Simon Horman <horms@...nel.org>,
 linux-arm-msm@...r.kernel.org, netdev@...r.kernel.org,
 linux-kernel@...r.kernel.org, bjorn.andersson@....qualcomm.com,
 chris.lew@....qualcomm.com, Deepak Kumar Singh
 <deepak.singh@....qualcomm.com>
Subject: Re: [PATCH] net: qrtr: Expand control port access to root

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?
-- 
pw-bot: defer