Question regarding AppArmor behaviour: profile not loaded automatically

I have a strange problem on one of my machines. Following the issue after loss of Wifi after update to apparmor 5.0

The machine has now the latest available version installed:

:~> LANG=C zypper se -si apparmor
Loading repository data...
Reading installed packages...

S  | Name                   | Type    | Version       | Arch   | Repository
---+------------------------+---------+---------------+--------+-----------
i+ | apparmor               | pattern | 20241218-29.1 | x86_64 | repo-oss
i+ | apparmor-abstractions  | package | 5.0.0-2.1     | noarch | repo-oss
i+ | apparmor-docs          | package | 5.0.0-2.1     | noarch | repo-oss
i+ | apparmor-parser        | package | 5.0.0-2.1     | x86_64 | repo-oss
i+ | apparmor-parser-lang   | package | 5.0.0-2.1     | noarch | repo-oss
i+ | apparmor-profiles      | package | 5.0.0-2.1     | noarch | repo-oss
i+ | apparmor-utils         | package | 5.0.0-2.1     | noarch | repo-oss
i+ | apparmor-utils-lang    | package | 5.0.0-2.1     | noarch | repo-oss
i+ | libapparmor1           | package | 5.0.0-2.1     | x86_64 | repo-oss
i+ | patterns-base-apparmor | package | 20241218-29.1 | x86_64 | repo-oss
i+ | python3-apparmor       | package | 5.0.0-2.1     | x86_64 | repo-oss
i  | yast2-apparmor         | package | 5.0.1-1.5     | noarch | repo-oss

After a every restart of the machine, Wifi is still lost and the Apparmor audit log shows:

type=AVC msg=audit(1779124359.083:447): apparmor="DENIED" operation="connect" class="file" info="Failed name lookup - disconnected path" error=-13 profile="wpa_supplicant" name="run/dbus/system_bus_socket" pid=2613 comm="wpa_supplicant" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

I need to force a reload of the wpa_supplicant profile and restart networkmanager. Afterwards Wifi works:

sudo apparmor_parser -r /etc/apparmor.d/wpa_supplicant
sudo systemctl restart NetworkManager

Two things are strange:

  • the audit log shows an obvious spelling error:
    requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0
    → no clue where this is coming from
  • after reload of the profile the spelling error is gone. Why does the profile not automatically get loaded at system start?

To say it with Queen: It’s a kind of magic…(or user error)

I had a wpa_supplicant.bak file under /etc/apparmor.d/. This was backup file when the initial Wifi bug was reported and i played with some modifications.
I comparred the output of aa-status before and after reload of the wpa_supplicant profile (apparmor_parser -r /etc/apparmor.d/wpa_supplicant). After reload the profile was in enforced mode.
So i tried again to enforce the wpa_supplicant file (aa-enforce wpa_supplicant
) and saw on the command line, that Apparmor stumbled over the *.bak file and therefore couldn’t load the original profile. After deletion of the *.bak file everything works.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.