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

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

[Vishnu Santhosh]

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.

Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
---
 net/qrtr/af_qrtr.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/qrtr/af_qrtr.c b/net/qrtr/af_qrtr.c
index dab839f61ee93b876021d904ae6b8dca8ed43745..b0e252c16f156c05973988fbdf317a149ad9840d 100644
--- a/net/qrtr/af_qrtr.c
+++ b/net/qrtr/af_qrtr.c
@@ -8,6 +8,7 @@
 #include <linux/qrtr.h>
 #include <linux/termios.h>	/* For TIOCINQ/OUTQ */
 #include <linux/spinlock.h>
+#include <linux/uidgid.h>
 #include <linux/wait.h>
 
 #include <net/sock.h>
@@ -738,7 +739,8 @@ static int qrtr_port_assign(struct qrtr_sock *ipc, int *port)
 	if (!*port) {
 		rc = xa_alloc(&qrtr_ports, port, ipc, QRTR_EPH_PORT_RANGE,
 				GFP_KERNEL);
-	} else if (*port < QRTR_MIN_EPH_SOCKET && !capable(CAP_NET_ADMIN)) {
+	} else if (*port < QRTR_MIN_EPH_SOCKET && !(capable(CAP_NET_ADMIN) ||
+						   in_egroup_p(GLOBAL_ROOT_GID))) {
 		rc = -EACCES;
 	} else if (*port == QRTR_PORT_CTRL) {
 		rc = xa_insert(&qrtr_ports, 0, ipc, GFP_KERNEL);

---
base-commit: f14faaf3a1fb3b9e4cf2e56269711fb85fba9458
change-id: 20260205-qrtr-control-port-access-permission-bfea19994a58

Best regards,
-- 
Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>

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

[Jijie Shao]

on 2026/2/5 16:21, 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.

Hi:

Sorry, I noticed that this patch has several check failures.
You may want to pay attention to this:
https://patchwork.kernel.org/project/netdevbpf/patch/20260205-qrtr-control-port-access-permission-v1-1-e900039e92d5@oss.qualcomm.com/

1.Single patches do not need cover letters; Target tree name not specified in the subject
2.WARNING: line length of 83 exceeds 80 columns
3.AI review found issues

Jijie Shao

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

[Jakub Kicinski]

On Fri, 6 Feb 2026 11:59:44 +0800 Jijie Shao wrote:
> Sorry, I noticed that this patch has several check failures.
> You may want to pay attention to this:
> https://patchwork.kernel.org/project/netdevbpf/patch/20260205-qrtr-control-port-access-permission-v1-1-e900039e92d5@oss.qualcomm.com/
> 
> 1.Single patches do not need cover letters; Target tree name not specified in the subject
> 2.WARNING: line length of 83 exceeds 80 columns
> 3.AI review found issues

This is not public CI, the maintainers will point out the issues
in the code if the failing checks are relevant.

If you'd like to help with code reviews please focus on that, 
reviewing the code. We do not need help with trivial process matters.

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

[Jakub Kicinski]

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

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

[Jijie Shao]

on 2026/2/7 10:34, Jakub Kicinski wrote:
> On Fri, 6 Feb 2026 11:59:44 +0800 Jijie Shao wrote:
>> Sorry, I noticed that this patch has several check failures.
>> You may want to pay attention to this:
>> https://patchwork.kernel.org/project/netdevbpf/patch/20260205-qrtr-control-port-access-permission-v1-1-e900039e92d5@oss.qualcomm.com/
>>
>> 1.Single patches do not need cover letters; Target tree name not specified in the subject
>> 2.WARNING: line length of 83 exceeds 80 columns
>> 3.AI review found issues
> This is not public CI, the maintainers will point out the issues
> in the code if the failing checks are relevant.
>
> If you'd like to help with code reviews please focus on that,
> reviewing the code. We do not need help with trivial process matters.

ok,

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

[Bjorn Andersson]

On Thu, Feb 05, 2026 at 01:51:31PM +0530, Vishnu Santhosh wrote:
> When qrtr is loaded as module, qrtr-ns runs from SELinux kmod_t
> domain.

It wasn't clear to me that "qrtr-ns" refers to the net/qrtr/ns.c, not
the deprecated "qrtr-ns" utility, until I spoke with Chris last night.

Perhaps it's just me, but I would appreciate if this was made a bit
clearer. Writing "QRTR NS" instead of "qrtr-ns" would have been
sufficient.

Regards,
Bjorn

> 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.
> 
> Co-developed-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Deepak Kumar Singh <deepak.singh@oss.qualcomm.com>
> Signed-off-by: Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> ---
>  net/qrtr/af_qrtr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/net/qrtr/af_qrtr.c b/net/qrtr/af_qrtr.c
> index dab839f61ee93b876021d904ae6b8dca8ed43745..b0e252c16f156c05973988fbdf317a149ad9840d 100644
> --- a/net/qrtr/af_qrtr.c
> +++ b/net/qrtr/af_qrtr.c
> @@ -8,6 +8,7 @@
>  #include <linux/qrtr.h>
>  #include <linux/termios.h>	/* For TIOCINQ/OUTQ */
>  #include <linux/spinlock.h>
> +#include <linux/uidgid.h>
>  #include <linux/wait.h>
>  
>  #include <net/sock.h>
> @@ -738,7 +739,8 @@ static int qrtr_port_assign(struct qrtr_sock *ipc, int *port)
>  	if (!*port) {
>  		rc = xa_alloc(&qrtr_ports, port, ipc, QRTR_EPH_PORT_RANGE,
>  				GFP_KERNEL);
> -	} else if (*port < QRTR_MIN_EPH_SOCKET && !capable(CAP_NET_ADMIN)) {
> +	} else if (*port < QRTR_MIN_EPH_SOCKET && !(capable(CAP_NET_ADMIN) ||
> +						   in_egroup_p(GLOBAL_ROOT_GID))) {
>  		rc = -EACCES;
>  	} else if (*port == QRTR_PORT_CTRL) {
>  		rc = xa_insert(&qrtr_ports, 0, ipc, GFP_KERNEL);
> 
> ---
> base-commit: f14faaf3a1fb3b9e4cf2e56269711fb85fba9458
> change-id: 20260205-qrtr-control-port-access-permission-bfea19994a58
> 
> Best regards,
> -- 
> Vishnu Santhosh <vishnu.santhosh@oss.qualcomm.com>
> 

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

[Manivannan Sadhasivam]

+ 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?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

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

[Stephen Smalley]

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.

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

[Vishnu Santhosh]

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.