Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
+++ 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
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.
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.
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