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.
(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.
(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
> > 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
*** Bug 2000112 has been marked as a duplicate of this bug. ***
> 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 device file names can change. In fact, the capital letters in the filename will only happen in Linux 5.12, 5.13 will have them all in lowercase, something like that. A wild match of /dev/wwan* may work, although not sure how desirable that would be? Can the selinux labeling happen for ALL devices of a given subsystem? i.e. all devices exposed by the "wwan" subsystem need to be accessible by /usr/sbin/ModemManager (ModemManager package), /usr/bin/qmicli and /usr/libexec/qmi-proxy (libqmi package) and /usr/bin/mbimcli and /usr/libexec/mbim-proxy (libmbim package). The "wwan" subsystem in the kernel is exclusively used by WWAN modems, so that may be a much better choice, if possible.
(In reply to Aleksander Morgado from comment #5) > > 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 device file names can change. In fact, the capital letters in the > filename will only happen in Linux 5.12, 5.13 will have them all in > lowercase, something like that. A wild match of /dev/wwan* may work, > although not sure how desirable that would be? We only care about 5.13+ and arguably with in around a month 5.14+ as Fedora will rebase at around 5.14.3
*** Bug 2036973 has been marked as a duplicate of this bug. ***
*** Bug 2036972 has been marked as a duplicate of this bug. ***
In the duplicates we can see the filenames wwan0at0 and wwan0mbim0. In the current kernel there seems to be: 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 };
I've submitted a Fedora draft PR to assign the proper type: https://github.com/fedora-selinux/selinux-policy/pull/1032 However, I still have these questions: 1. Due to the unpredictable file name, file transitions are not a part of the commit. Will it be possible to have an udev rule to run restorecon after the device file is created? 2. Are these /usr/bin/mbimcli and /usr/bin/qmicli executables executed by a user or in a user session, or rather by a confined service like ModemManager? 3. How these ones are executed? Is there a systemd service, or is it planned to have it? /usr/libexec/qmi-proxy /usr/libexec/mbim-proxy Note after decoding path=006D62696D2D70726F7879 it turned out to be mbim-proxy.
> 1. Due to the unpredictable file name, file transitions are not a part of the commit. Will it be possible to have an udev rule to run restorecon after the device file is created? Isn't it really possible to tag the device files based on the "wwan" subsystem? That's definitely the cleanest way forward if subsystem matching is possible. I don't know enough about SELinux to reply about the restorecon udev rule. > Are these /usr/bin/mbimcli and /usr/bin/qmicli executables executed by a user or in a user session, or rather by a confined service like ModemManager? Both. Users can use mbimcli and qmicli, which has always been the main purpose. But, since MM 1.18.4, ModemManager may also use them itself in order to run custom FCC unlock scripts. > How these ones are executed? Is there a systemd service, or is it planned to have it? > /usr/libexec/qmi-proxy /usr/libexec/mbim-proxy The usual way to have them launched is by ModemManager itself. Those proxies listen on an abstract unix domain socket; MM tries to talk to them on boot, and if they don't reply, MM itself spawns them. There's no systemd service expected for them, although I know some setups that launch the proxies before MM itself, usually to launch them with custom command line options.
(In reply to Aleksander Morgado from comment #11) > > 1. Due to the unpredictable file name, file transitions are not a part of the commit. Will it be possible to have an udev rule to run restorecon after the device file is created? > > Isn't it really possible to tag the device files based on the "wwan" > subsystem? That's definitely the cleanest way forward if subsystem matching > is possible. I don't know enough about SELinux to reply about the restorecon > udev rule. Currently it is not possible to handle the transition in selinux-policy for unpredictable file names, we can only add filenames with regexp to file context specification so that restorecon can be run. I see udev rules as the only way forward to label the devices properly as soon as the device feil is created. > > Are these /usr/bin/mbimcli and /usr/bin/qmicli executables executed by a user or in a user session, or rather by a confined service like ModemManager? > > Both. Users can use mbimcli and qmicli, which has always been the main > purpose. But, since MM 1.18.4, ModemManager may also use them itself in > order to run custom FCC unlock scripts. > > > How these ones are executed? Is there a systemd service, or is it planned to have it? > > /usr/libexec/qmi-proxy /usr/libexec/mbim-proxy > > The usual way to have them launched is by ModemManager itself. Those proxies > listen on an abstract unix domain socket; MM tries to talk to them on boot, > and if they don't reply, MM itself spawns them. There's no systemd service > expected for them, although I know some setups that launch the proxies > before MM itself, usually to launch them with custom command line options. Thanks for the explanation, it means no further action can be done on our side, I'll clone this bz.
Merged for rawhide and F35.
FEDORA-2022-20f36a8b0e has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e
FEDORA-2022-20f36a8b0e has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-20f36a8b0e` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Confirmed working in F35 with the latest selinux-policy-35.13-1.fc35 https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e https://koji.fedoraproject.org/koji/buildinfo?buildID=1911501 Thanks all!
(In reply to Rhys Oxenham from comment #16) > Confirmed working in F35 with the latest selinux-policy-35.13-1.fc35 Rhys, Does that mean the device files have correct labels out of the box, or did you need to perform some action?
(In reply to Zdenek Pytela from comment #17) > (In reply to Rhys Oxenham from comment #16) > > Confirmed working in F35 with the latest selinux-policy-35.13-1.fc35 > > Rhys, > > Does that mean the device files have correct labels out of the box, or did > you need to perform some action? Hi Zdenek, I installed the SELinux policy files as per https://bodhi.fedoraproject.org/updates/FEDORA-2022-20f36a8b0e, re-enabled SELinux, and rebooted: % rpm -qa | grep selinux-policy selinux-policy-35.13-1.fc35.noarch selinux-policy-targeted-35.13-1.fc35.noarch % getenforce Enforcing % ls -laZ /dev/wwan0* crw-------. 1 root root system_u:object_r:modem_device_t:s0 243, 2 Feb 3 13:45 /dev/wwan0at0 crw-------. 1 root root system_u:object_r:modem_device_t:s0 243, 1 Feb 3 13:45 /dev/wwan0mbim0 crw-------. 1 root root system_u:object_r:modem_device_t:s0 243, 0 Feb 3 13:45 /dev/wwan0qcdm0 I then attempted to connect using the 5G modem, and it successfully connected without any errors/warnings, and I was able to access the internet. Thanks!
FEDORA-2022-20f36a8b0e has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.