Bug 1219363

I'll have a look, thanks for the report

so I played a bit with ModemManager, but I don't see the AVC. Can you please share details about your network setup? Also: When do you see this AVC? During startup? When you restart the network? Thanks

I need additional information please, otherwise I can't fix this

(In reply to Johannes Segitz from comment #2)
> so I played a bit with ModemManager, but I don't see the AVC. Can you please
> share details about your network setup? Also: When do you see this AVC?
> During startup? When you restart the network? Thanks

Sorry, I was at FOSDEM, and now I have holidays. My computer is connected to the network via Ethernet cable and via wifi. I don’t think I use anything which would require ModemManager.

I see it after setup when checking AVCs (because of otherwise broken system, but I think that is without relationship to SELinux).

(In reply to Matej Cepl from comment #4)
> I see it after setup when checking AVCs (because of otherwise broken system,
> but I think that is without relationship to SELinux).

BTW, yes I have fixed my system, and it had nothing to do with SELinux (gh#containers/podman#18514; who thought that this brittle system should be the foundation of everything is crazy).

And yes, I see this still around:

mitmanek:~ # ausearch -m AVC -ts boot
----
time->Sun Feb 18 08:47:43 2024
type=AVC msg=audit(1708242463.365:43): avc:  denied  { execmem } for  pid=1240 comm="ModemManager" scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:system_r:modemmanager_t:s0 tclass=process permissive=1
----
time->Sun Feb 18 14:32:13 2024
type=AVC msg=audit(1708263133.709:117): avc:  denied  { execmem } for  pid=1240 comm="ModemManager" scontext=system_u:system_r:modemmanager_t:s0 tcontext=system_u:system_r:modemmanager_t:s0 tclass=process permissive=1
----
time->Wed Feb 21 10:01:32 2024
type=AVC msg=audit(1708506092.952:5232): avc:  denied  { nlmsg_read } for  pid=23343 comm="ss" scontext=system_u:system_r:container_t:s0:c307,c487 tcontext=system_u:system_r:container_t:s0:c307,c487 tclass=netlink_tcpdiag_socket permissive=1
mitmanek:~ #

hm, can you based on the timestamp identify when this is happening? E.g. is this happening then the service starts? Or when you log into you desktop environment?
In the first case: Can you re-trigger the AVC by restarting the service?
In the second case: an you re-trigger the AVC by logging out of you GUI and then back in?

Without me being able to reproduce it this is unfortunately going to be a bit tedious.

(In reply to Johannes Segitz from comment #6)
> hm, can you based on the timestamp identify when this is happening? E.g. is
> this happening then the service starts? Or when you log into you desktop
> environment?

9 seconds after the beginning of the boot, so I guess somewhere during the boot process.

systemctl status says:

● ModemManager.service - Modem Manager
     Loaded: loaded (/usr/lib/systemd/system/ModemManager.service; enabled; preset: enabled)
     Active: active (running) since Wed 2024-02-28 18:47:25 CET; 2 days ago
   Main PID: 1209 (ModemManager)
      Tasks: 4 (limit: 4915)
        CPU: 341ms
     CGroup: /system.slice/ModemManager.service
             └─1209 /usr/sbin/ModemManager

úno 28 18:47:25 mitmanek.cepl.eu systemd[1]: Started Modem Manager.
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:08.3/0000:34:00.4/usb10/10-1/10-1.1': not >
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <info>  [device /sys/devices/pci0000:00/0000:00:08.1/0000:33:00.3/usb1/1-4] creating modem with plugin 'quectel' and '3' ports
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <warn>  [plugin/quectel] could not grab port cdc-wdm0: Cannot add port 'usbmisc/cdc-wdm0', unhandled port type
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <info>  [base-manager] modem for device '/sys/devices/pci0000:00/0000:00:08.1/0000:33:00.3/usb1/1-4' successfully created
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <info>  [modem0] state changed (unknown -> locked)
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <warn>  [modem0] modem couldn't be initialized: Couldn't check unlock status: SIM not inserted
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <info>  [modem0] state changed (locked -> failed)
úno 28 18:47:28 mitmanek.cepl.eu ModemManager[1209]: <warn>  [modem0] error initializing: Modem in failed state: sim-missing
úno 28 18:47:29 mitmanek.cepl.eu ModemManager[1209]: <info>  [base-manager] couldn't check support for device '/sys/devices/pci0000:00/0000:00:02.2/0000:01:00.0': not supported by any p>


> In the first case: Can you re-trigger the AVC by restarting the service?
> In the second case: an you re-trigger the AVC by logging out of you GUI and
> then back in?

Let me check it and write next comment.

It is apparently a system level service, logging out of the sway doesn't change the start when it was run.

Logging out of the window manager doesn't change anything, but when I now use laptop as a laptop, out of the docking station, it happens on every resume from suspendend state.

okay I think I know why this doesn't happen. Your laptop has a modem, my VM doesn't. I try to attach something to the VM to trigger the behavior

and I can reproduce it :) I'll try to figure out if it's necessary or not. execmem isn't something I'd like to grant

Is https://bugzilla.redhat.com/show_bug.cgi?id=2149946 the same?

yes, it's the same. Found that also, but it doesn't contain a solution.

It's not easy to debug due to the multithreaded design. If you run it without udev/audo device discovery this doesn't happen

it's the regexp parser in glib. Probably some optimization, I'll dig a bit deeper

it's the JIT. If this is disabled performance is a bit worse, but nothing else. I'll dontaudit this

I just merged this in our git. As this has no ill effects we'll just take this with the next policy update