Hi Steve Langasek, thanks for taking a look at the SRU. > Is that not what this means, or is mqueue access actually denied by > default and this refers only to how an unqualified 'mqueue' rule is > interpreted?
Correct, this only refers to how an unqualified 'mqueue' rule is interpreted. > In that case how does introducing mqueue support in apparmor benefit > users of jammy? Users of jammy will now have the ability to mediate message queues in their profile if they want, but they will have to opt-in. There is more than one way to accomplish this, but they can for example add 'abi <kernel>,' to their profile when using a kernel that provides mqueue mediation. That means that older policies that were developed when mqueue mediation was not available will not be broken. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apparmor in Ubuntu. https://bugs.launchpad.net/bugs/1994146 Title: [SRU] apparmor - Focal, Jammy Status in apparmor package in Ubuntu: Confirmed Status in apparmor source package in Focal: In Progress Status in apparmor source package in Jammy: Incomplete Bug description: [ Impact ] This is a SRU proposal for apparmor in Focal and Jammy. For focal, we want to SRU fixes for Bug 1964636 which introduces the capability upstream patches. We are also fixing Bug 1728130 and Bug 1993353 which are introducing full backport of abi from apparmor-3.0 and support for POSIX message queue rules, which are both a request from Honeywell. Note that specifically for message queue rules, we are overriding the abi behavior. Message queue mediation is not a part of the 2.13 abi we are pinning. Honeywell has a kernel that has message queue mediation, but their policy does not contain an abi specified, so when we pin the abi for a kernel that does not mediate message queue, it will break Honeywell's AppArmor policies. So we are making an exception: when abi is not specified in the policy, and the policy contain mqueue rules, we are enforcing mqueue rules. When the policy does not contain mqueue rules, then they are not being enforced. This is so we do not break Honeywell policies and we also are not breaking policies that were developed when there was no mqueue or abi support. For jammy, we are SRUing fixes for Bug 1993353 which adds message queue rules support. [ Test Plan ] This has been extensively tested by using QA Regression Tests[1] for AppArmor. All tests have passed and demonstrated AppArmor to be working as expected. We are also adding regression tests for message queue rules[2] which guarantees it is working as expected. [1] https://git.launchpad.net/qa-regression-testing/tree/scripts/test-apparmor.py [2] https://gitlab.com/apparmor/apparmor/-/merge_requests/858 [ Where problems could occur ] The message queue rules support could cause issues for AppArmor policies that were developed before there was support for mqueues, that's why we are also backporting abi support and pinning the abi on parser.conf on focal. Jammy already has the abi pinned for a kernel that does not have support for mqueue mediation. [ Other Info ] The patches for both focal and jammy can be found at: https://launchpad.net/~georgiag/+archive/ubuntu/mqueue-sru/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1994146/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
