Please update udev rules for /dev/wwan.* so that restorecon is executed on the filename when it is created. It cannot be done by a file transition in selinux-policy, but default file context works with regexps so restorecon will work.

+++ 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 15:24:15 CEST ---

(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 15:58:38 CEST ---

(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 16:15:09 CEST ---

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

--- Additional comment from Peter Robinson on 2021-09-01 16:54:51 CEST ---



--- Additional comment from Aleksander Morgado on 2021-09-01 17:58:59 CEST ---

> 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.

--- Additional comment from Peter Robinson on 2021-09-01 18:40:50 CEST ---

(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

--- Additional comment from Zdenek Pytela on 2022-01-12 19:21:55 CET ---



--- Additional comment from Zdenek Pytela on 2022-01-12 19:22:02 CET ---



--- Additional comment from Zdenek Pytela on 2022-01-12 19:24:27 CET ---

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 };

--- Additional comment from Zdenek Pytela on 2022-01-28 17:37:23 CET ---

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.

--- Additional comment from Aleksander Morgado on 2022-01-29 10:57:41 CET ---

> 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.

--- Additional comment from Zdenek Pytela on 2022-02-01 16:01:12 CET ---

(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.