Section 1.3.1.3 runs into errors with unconfined processes

[Luiggi33]

Describe the problem

When running the example playbook on a fresh iso install, a error stops the run at section 1.3.1.3
This is a expected error when trying to change AppArmor processes, which are unconfined into complain or enforce mode. This should either be a handled error or something similar

Expected behavior

The example playbook should run through

What is version of application which has the issue?

commit 14e7c75

What was the last working version of the application?

No response

What type of installation are you running?

OS (setup.py)

What type of device you use to interact with the application?

OS: [e.g. linux, windows, ios]

Example JSON snippet

No response

Anything in the logs that might be useful for us?

TASK [ansible-cis-ubuntu-2404 : SECTION1 | 1.3.1.3 | Ensure all AppArmor Profiles are in enforce or complain mode] ***
fatal: [192.168.168.129]: FAILED! => {"changed": false, "cmd": ["/usr/sbin/aa-complain", "/etc/apparmor.d/*"], "delta": "0:00:00.315043", "end": "2024-10-18 22:14:18.027420", "msg": "non-zero return code", "rc": 1, "start": "2024-10-18 22:14:17.712377", "stderr": "Traceback (most recent call last):\n  File \"/usr/sbin/aa-complain\", line 33, in <module>\n    tool.cmd_complain()\n  File \"/usr/lib/python3/dist-packages/apparmor/tools.py\", line 140, in cmd_complain\n    for (program, prof_filename, output_name) in self.get_next_for_modechange():\n  File \"/usr/lib/python3/dist-packages/apparmor/tools.py\", line 97, in get_next_for_modechange\n    aaui.UI_Info(_('Profile for %s not found, skipping') % output_name)\n                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\nTypeError: 'NoneType' object is not callable\n\n\nAn unexpected error occurred!\n\nFor details, see /tmp/apparmor-bugreport-vj14tzer.txt\nPlease consider reporting a bug at https://gitlab.com/apparmor/apparmor/-/issues\nand attach this file.", "stderr_lines": ["Traceback (most recent call last):", "  File \"/usr/sbin/aa-complain\", line 33, in <module>", "    tool.cmd_complain()", "  File \"/usr/lib/python3/dist-packages/apparmor/tools.py\", line 140, in cmd_complain", "    for (program, prof_filename, output_name) in self.get_next_for_modechange():", "  File \"/usr/lib/python3/dist-packages/apparmor/tools.py\", line 97, in get_next_for_modechange", "    aaui.UI_Info(_('Profile for %s not found, skipping') % output_name)", "                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^", "TypeError: 'NoneType' object is not callable", "", "", "An unexpected error occurred!", "", "For details, see /tmp/apparmor-bugreport-vj14tzer.txt", "Please consider reporting a bug at https://gitlab.com/apparmor/apparmor/-/issues", "and attach this file."], "stdout": "", "stdout_lines": []}

Additional information

No response

[MVladislav]

It seems that something has changed since Ubuntu 24.04, preventing the command from running in the same way it worked with previous versions. Specifically, the error message states that the profile is "Profile for %s not found, skipping".

At the moment, I haven't found an easy solution to ensure this rule runs successfully. Therefore, I’ve temporarily documented this issue in the README and disabled the affected rule by default:

This issue is on my list to fix and improve.
Any feedback or suggestions are appreciated in the meantime.

This issue is on my list to fix and improve.

Additionally, improvements need to be made for this part of the playbook. Previously, I moved everything into complain mode using the aa-complain command, even when a service was already in enforce mode. This behavior is not ideal, and the playbook should be updated to ensure it only moves services into complain mode if they are not already in enforce. This will prevent services already in enforce from being unnecessarily changed.

Any feedback or suggestions are appreciated in the meantime.

[Luiggi33]

It seems that something has changed since Ubuntu 24.04, preventing the command from running in the same way it worked with previous versions. Specifically, the error message states that the profile is "Profile for %s not found, skipping".

This actually seems to be an AppArmor bug, which should be fixed with the next patchset (https://gitlab.com/apparmor/apparmor/-/issues/411)

Additionally, improvements need to be made for this part of the playbook. Previously, I moved everything into complain mode using the aa-complain command, even when a service was already in enforce mode. This behavior is not ideal, and the playbook should be updated to ensure it only moves services into complain mode if they are not already in enforce. This will prevent services already in enforce from being unnecessarily changed.

Any feedback or suggestions are appreciated in the meantime.

I think the easiest solution would be to give a config value to either put everything into enforce or complain mode. In addition you probably would need to check if 1.3.1.4 (everything needs to be enforced) is set and if so, just enforce everything

[MVladislav]

I’ve added an updated version with the following changes:

• For cis_ubuntu2404_rule_1_3_1_3, it will now only check for profiles that are unconfined and change them to complain.
• For cis_ubuntu2404_rule_1_3_1_4, it will check for profiles that are either unconfined or complain and change them to enforce. (While this isn't strictly necessary, it standardizes the process.)
• Currently, the execution of aa-enforce and aa-complain will ignore errors. This will prevent failures as long as the AppArmor bug remains unresolved; this behavior will be removed in a future update.
• Additionally, you can now define which profiles to change to complain or enforce by setting the variables cis_ubuntu2404_apparmor_update_to_complain_profiles and cis_ubuntu2404_apparmor_update_to_enforce_profiles.

Let me know what you think about these changes, and feel free to share any suggestions for improvement or if you spot any errors.

Thanks for your research and support! 😊

[Luiggi33]

That looks perfect, I will rerun it on my side tomorrow and give feedback accordingly

[Luiggi33]

The complain rule has worked as expected. I applied the fix from https://gitlab.com/apparmor/apparmor/-/merge_requests/1218 manually, as to have a "clean" result and all unconfined profiles got set.
Only MongoDB Compass, firefox and vscode were not put into any mode, which I would expect is more a AppArmor issue, because they were set according to the Ansible output.
I would assume this issue is resolved

[MVladislav]

Thank you for taking the time to test this.

Only MongoDB Compass, firefox and vscode were not put into any mode, which I would expect is more a AppArmor issue, because they were set according to the Ansible output.

Yes, I would agree with that, and it's something I also noticed during testing.

Once the fix is publicly available, I can remove the section that ignores errors in the task.

ansible-cis-ubuntu-2404/tasks/section1.yml

Line 640 in fa68da6

failed_when: false # NOTE: this should be later removed when bug for AppArmor is fixed

ansible-cis-ubuntu-2404/tasks/section1.yml

Line 663 in fa68da6

failed_when: false # NOTE: this should be later removed when bug for AppArmor is fixed