2000196 – SELinux prevents WWAN ports being accessed (Qualcomm SDX55)

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2000196 - SELinux prevents WWAN ports being accessed (Qualcomm SDX55)

Summary: SELinux prevents WWAN ports being accessed (Qualcomm SDX55)

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 9
Classification:	Red Hat
Component:	selinux-policy
Sub Component:
Version:	9.0
Hardware:	x86_64
OS:	Linux
Priority:	medium
Severity:	medium
Target Milestone:	rc
Target Release:	9.0
Assignee:	Zdenek Pytela
QA Contact:	Milos Malik
Docs Contact:
URL:
Whiteboard:
Depends On:	1961571 2049128
Blocks:	IoT
TreeView+	depends on / blocked

Reported:	2021-09-01 14:41 UTC by Peter Robinson
Modified:	2022-05-17 16:11 UTC (History)
CC List:	12 users (show)
Fixed In Version:	selinux-policy-34.1.27-1.el9
Doc Type:	No Doc Update
Doc Text:
Clone Of:	1961571
Environment:
Last Closed:	2022-05-17 15:49:48 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHELPLAN-95894	0	None	None	None	2021-09-01 14:43:00 UTC
Red Hat Product Errata	RHBA-2022:3918	0	None	None	None	2022-05-17 15:50:00 UTC

Description Peter Robinson 2021-09-01 14:41:52 UTC

+++ This bug was initially created as a clone of Bug #1961571 +++

Description of problem:

The default SELinux policy on Fedora 34 prevents the enumerated Qualcomm SDX55-based MBIM devices from being accessed by ModemManager (and likely other resources, or other devices that utilise MBIM).

Version-Release number of selected component (if applicable):

# rpm -qa | egrep '(kernel-5.13|ModemManager|mbim|qmi|selinux-policy)'
kernel-5.13.0-0.rc1.13.rdo.fc35.x86_64
libmbim-1.25.4-1.fc34.x86_64
libmbim-devel-1.25.4-1.fc34.x86_64
libmbim-utils-1.25.4-1.fc34.x86_64
ModemManager-glib-1.17.1-1.fc34.x86_64
ModemManager-1.17.1-1.fc34.x86_64
ModemManager-devel-1.17.1-1.fc34.x86_64
selinux-policy-34.7-1.fc34.noarch
selinux-policy-targeted-34.7-1.fc34.noarch
libqmi-1.29.5-2.fc34.x86_64
libqmi-utils-1.29.5-2.fc34.x86_64
libqmi-devel-1.29.5-2.fc34.x86_64

How reproducible:

Every time. I've got to disable SELinux to get it to work as expected.

Actual results:

Under SELinux permissive mode I've captured the audit logs to show which were denied:

type=AVC msg=audit(1621331844.977:1196): avc:  denied  { read write } for  pid=27570 comm="ModemManager" name="wwan0p1QCDM" dev="devtmpfs" ino=692 scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1621331844.977:1197): avc:  denied  { open } for  pid=27570 comm="ModemManager" path="/dev/wwan0p1QCDM" dev="devtmpfs" ino=692 scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1621331844.977:1198): avc:  denied  { getattr } for  pid=27570 comm="pool-ModemManag" path="/dev/wwan0p2MBIM" dev="devtmpfs" ino=694 scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1621331845.255:1199): avc:  denied  { ioctl } for  pid=27570 comm="ModemManager" path="/dev/wwan0p1QCDM" dev="devtmpfs" ino=692 ioctlcmd=0x5401 scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
type=AVC msg=audit(1621331845.273:1200): avc:  denied  { connectto } for  pid=27570 comm="ModemManager" path=006D62696D2D70726F7879 scontext=system_u:system_r:modemmanager_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1


Expected results:

SELinux policy allows ModemManager to access the MBIM/QCDM devices.

--- Additional comment from Zdenek Pytela on 2021-05-18 13:24:15 UTC ---

(In reply to Rhys Oxenham from comment #0)
> type=AVC msg=audit(1621331844.977:1196): avc:  denied  { read write } for 
> pid=27570 comm="ModemManager" name="wwan0p1QCDM" dev="devtmpfs" ino=692
> scontext=system_u:system_r:modemmanager_t:s0
> tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
These denials will be addressed by assigning proper label to the device, as a result allowing the access to all services which already had the permissions. The most tricky part is to understand how the filename is constructed. Will the filenames wwan0p1QCDM and wwan0p2MBIM always be the same or can they change?

The problem is that while we can assign a default label in selinux-policy to filename with regular expressions, file transitions need to be enumerated unless the device label is handled by the driver itself.

> type=AVC msg=audit(1621331845.273:1200): avc:  denied  { connectto } for 
> pid=27570 comm="ModemManager" path=006D62696D2D70726F7879
> scontext=system_u:system_r:modemmanager_t:s0
> tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> tclass=unix_stream_socket permissive=1
To understand this denial, we need to find out which service ModemManager communicates with: do you happen to know which service it is and how it was started? If it is still running, with this command we can find it?

ps -eo pid,ppid,command,context | grep -e CONTEXT -e unconfined_t

> 
> 
> Expected results:
> 
> SELinux policy allows ModemManager to access the MBIM/QCDM devices.

--- Additional comment from Rhys Oxenham on 2021-05-19 13:58:38 UTC ---

(In reply to Zdenek Pytela from comment #1)

> > type=AVC msg=audit(1621331844.977:1196): avc:  denied  { read write } for 
> > pid=27570 comm="ModemManager" name="wwan0p1QCDM" dev="devtmpfs" ino=692
> > scontext=system_u:system_r:modemmanager_t:s0
> > tcontext=system_u:object_r:device_t:s0 tclass=chr_file permissive=1
> These denials will be addressed by assigning proper label to the device, as
> a result allowing the access to all services which already had the
> permissions. The most tricky part is to understand how the filename is
> constructed. Will the filenames wwan0p1QCDM and wwan0p2MBIM always be the
> same or can they change?

That's a good question, unfortunately I can only answer it from my perspective and with my modem.

From what I can see, the kernel mhi subsystem adds in the wwan0pX ports, and the subports refer to different ways of interrogating the ports, e.g. p1 is QCDM format, and p2 is MBIM.

Whilst I don't have it listed, it's also possible of enabling standard "AT" serial interrogation of a device, so this would likely get listed as "wwan0p3AT"

Every reboot, *my* devices get enumerated in the same way, but I suspect it's entirely possible that other devices (or if you had >1 device) they would get enumerated in different ways.

> 
> The problem is that while we can assign a default label in selinux-policy to
> filename with regular expressions, file transitions need to be enumerated
> unless the device label is handled by the driver itself.
> 
> > type=AVC msg=audit(1621331845.273:1200): avc:  denied  { connectto } for 
> > pid=27570 comm="ModemManager" path=006D62696D2D70726F7879
> > scontext=system_u:system_r:modemmanager_t:s0
> > tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> > tclass=unix_stream_socket permissive=1
> To understand this denial, we need to find out which service ModemManager
> communicates with: do you happen to know which service it is and how it was
> started? If it is still running, with this command we can find it?
> 
> ps -eo pid,ppid,command,context | grep -e CONTEXT -e unconfined_t
> 

I *believe* that it's actually `mbim-proxy` in my case that interrogates the wwan0p2MBIM port from ModemManager.

Results from that command above, although I don't think they're particularly useful for you, note that I'm currently in permissive mode, not sure it matters-

% ps -eo pid,ppid,command,context | grep -e CONTEXT -e unconfined_t
    PID    PPID COMMAND                     CONTEXT
   1872       1 /usr/lib/systemd/systemd -- unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   1888    1863 sshd: rdo@pts/0             unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   1896    1888 -zsh                        unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   1953    1924 /usr/libexec/gdm-wayland-se unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   1962    1953 /usr/libexec/gnome-session- unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2009    1872 /usr/libexec/gnome-session- unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2010    1872 /usr/libexec/uresourced --u unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2012    1872 /usr/libexec/gnome-session- unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2035    1872 /usr/bin/gnome-keyring-daem unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2053    1872 /usr/bin/gnome-shell        unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2119    1872 /usr/libexec/at-spi-bus-lau unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2139    2053 ibus-daemon --panel disable unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2142    1872 /usr/libexec/gvfsd          unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2147    1872 /usr/libexec/gvfsd-fuse /ru unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2149    2139 /usr/libexec/ibus-dconf     unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2150    2139 /usr/libexec/ibus-extension unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2155    1872 /usr/libexec/ibus-portal    unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2169    1872 /usr/libexec/xdg-permission unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2173    1872 /usr/libexec/gnome-shell-ca unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2179    1872 /usr/libexec/evolution-sour unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2183    1872 /usr/bin/pipewire           unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2184    1872 /usr/bin/pipewire-pulse     unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2190    2183 /usr/bin/pipewire-media-ses unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2194    1872 /usr/libexec/goa-daemon     unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2200    1872 /usr/libexec/evolution-cale unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2206    1872 /usr/libexec/gvfs-udisks2-v unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2215    1872 /usr/libexec/gvfs-mtp-volum unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2221    1872 /usr/libexec/gvfs-gphoto2-v unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2232    1872 /usr/libexec/gvfs-goa-volum unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2234    1872 /usr/libexec/dconf-service  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2243    1872 /usr/libexec/evolution-addr unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2253    1872 /usr/libexec/goa-identity-s unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2258    1872 /usr/libexec/gvfs-afc-volum unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2279    1872 /usr/bin/gjs /usr/share/gno unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2280    1872 /usr/libexec/at-spi2-regist unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2298    1872 /usr/libexec/gsd-a11y-setti unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2299    1872 /usr/libexec/gsd-color      unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2303    1872 /usr/libexec/gsd-datetime   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2307    1872 /usr/libexec/gsd-housekeepi unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2308    1872 /usr/libexec/gsd-keyboard   unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2310    1872 /usr/libexec/gsd-media-keys unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2315    1872 /usr/libexec/gsd-power      unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2319    1872 /usr/libexec/gsd-print-noti unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2320    1872 /usr/libexec/gsd-rfkill     unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2324    1872 /usr/libexec/gsd-screensave unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2328    1872 /usr/libexec/gsd-sharing    unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2329    1872 /usr/libexec/gsd-smartcard  unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2332    1872 /usr/libexec/gsd-sound      unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2336    1872 /usr/libexec/gsd-usb-protec unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2341    1872 /usr/libexec/gsd-wacom      unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2367    2012 /usr/libexec/evolution-data unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2371    2012 /usr/libexec/gsd-disk-utili unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2398    2012 /usr/bin/gnome-software --g unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2425    1872 /usr/bin/abrt-applet --gapp unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2426    1872 /usr/bin/gjs /usr/share/gno unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2473    2139 /usr/libexec/ibus-engine-si unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   2518    1872 /usr/libexec/gsd-printer    unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   3112    1896 ps -eo pid,ppid,command,con unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
   3113    1896 grep --color=auto -e CONTEX unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

--- Additional comment from Peter Robinson on 2021-05-19 14:15:09 UTC ---

> > constructed. Will the filenames wwan0p1QCDM and wwan0p2MBIM always be the
> > same or can they change?
> From what I can see, the kernel mhi subsystem adds in the wwan0pX ports, and
> the subports refer to different ways of interrogating the ports, e.g. p1 is
> QCDM format, and p2 is MBIM.

I suspect it's the new WWAN kernel interface that adds these:
https://cateee.net/lkddb/web-lkddb/WWAN.html

It will be wwanXpY where X is the device, and most of the devices have a bunch of ports for things like control, IP, location etc.

> > ps -eo pid,ppid,command,context | grep -e CONTEXT -e unconfined_t
> > 
> 
> I *believe* that it's actually `mbim-proxy` in my case that interrogates the
> wwan0p2MBIM port from ModemManager.

Could also be qmi-proxy

Comment 1 Zdenek Pytela 2022-01-24 15:21:26 UTC

Ondrej,

I believe the proper type for these devices is modem_device_t, but I am not sure about the device file names: Will it always be the same or is it completely unpredictable?
Can this change in the near future?
Can you answer this or forward to someone else?

This is in Fedora 5.16 kernel:
drivers/net/wwan/wwan_core.c
 229 /* ------- WWAN port management ------- */
 230
 231 static const struct {
 232         const char * const name;        /* Port type name */
 233         const char * const devsuf;      /* Port devce name suffix */
 234 } wwan_port_types[WWAN_PORT_MAX + 1] = {
 235         [WWAN_PORT_AT] = {
 236                 .name = "AT",
 237                 .devsuf = "at",
 238         },
 239         [WWAN_PORT_MBIM] = {
 240                 .name = "MBIM",
 241                 .devsuf = "mbim",
 242         },
 243         [WWAN_PORT_QMI] = {
 244                 .name = "QMI",
 245                 .devsuf = "qmi",
 246         },
 247         [WWAN_PORT_QCDM] = {
 248                 .name = "QCDM",
 249                 .devsuf = "qcdm",
 250         },
 251         [WWAN_PORT_FIREHOSE] = {
 252                 .name = "FIREHOSE",
 253                 .devsuf = "firehose",
 254         },
 255 };

include/linux/wwan.h:
 14 /**
 15  * enum wwan_port_type - WWAN port types
 16  * @WWAN_PORT_AT: AT commands
 17  * @WWAN_PORT_MBIM: Mobile Broadband Interface Model control
 18  * @WWAN_PORT_QMI: Qcom modem/MSM interface for modem control
 19  * @WWAN_PORT_QCDM: Qcom Modem diagnostic interface
 20  * @WWAN_PORT_FIREHOSE: XML based command protocol
 21  *
 22  * @WWAN_PORT_MAX: Highest supported port types
 23  * @WWAN_PORT_UNKNOWN: Special value to indicate an unknown port type
 24  * @__WWAN_PORT_MAX: Internal use
 25  */
 26 enum wwan_port_type {
 27         WWAN_PORT_AT,
 28         WWAN_PORT_MBIM,
 29         WWAN_PORT_QMI,
 30         WWAN_PORT_QCDM,
 31         WWAN_PORT_FIREHOSE,
 32
 33         /* Add new port types above this line */
 34
 35         __WWAN_PORT_MAX,
 36         WWAN_PORT_MAX = __WWAN_PORT_MAX - 1,
 37         WWAN_PORT_UNKNOWN,
 38 };

In RHEL 9 there is kernel-5.14. We need to have solutions for both.

Comment 2 Ondrej Mosnacek 2022-01-25 09:33:43 UTC

It seems that in kernel 5.13 (where this was introduced) the device name was of the form "/dev/wwan<WWAN_device_ID>p<unique_port_number><type>" (where <type> is one of "AT", "MBIM", "QMI", "QCDM", "FIREHOSE") and in 5.14 and later this changed to "/dev/wwan<WWAN_device_ID><type><unique_port_number>" (commit f458709ff40b), with <type> changing to lowercase (commit 392c26f7f133). There are also "/dev/wwan<WWAN_device_ID>" devices, which are parent devices of these port devices. AFAICT, <WWAN_device_ID> can range from 0 to INT_MAX and <unique_port_number> from 0 to PAGE_SIZE * 8. At least that's what I was able to read out of the kernel code...

Not sure how likely the name format is to change again (I would hope they already settled on the right format...). New values for <type> are definitely possible, not sure how frequent. One way or another, it won't be possible to fully cover these devices by named type transition rules (unless we get prefix/suffix support).

I agree with modem_device_t as the type.

Comment 3 Zdenek Pytela 2022-02-01 15:09:01 UTC

Commits to backport:
commit 51422c4a4277924046514a18b67a38b896d698f0 (HEAD -> rawhide, upstream/rawhide)
Author: Zdenek Pytela <zpytela>
Date:   Fri Jan 28 17:40:25 2022 +0100

    Allow ModemManager connect to the unconfined user domain

commit 80a2e3a855c20a6b1397837037e84c9657fd280f
Author: Zdenek Pytela <zpytela>
Date:   Fri Jan 28 17:16:15 2022 +0100

    Label /dev/wwan.+ with modem_manager_t

Comment 20 errata-xmlrpc 2022-05-17 15:49:48 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: selinux-policy), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:3918

Note You need to log in before you can comment on or make changes to this bug.