Comment 27 for bug 1964636

Revision history for this message
Heather Lemon (hypothetical-lemon) wrote :

Lukasz is correct, we should be diligent in backporting the upstream patches. In regards to testing it's important to ensure apparmor and its new features work as intended with no errors in logs.
As well as apparmor not quitting after a restart. All three effected LP's should be thoroughly tested.

There are over 20 patches being backported from upstream apparmor3.0
They fall into 3 categories.
1. capabilities improvements (maintain and generate the capabilities list used by apparmor)
2. abi [0]
3. mqueue

[0] https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorpolicyfeaturesabi#why-were-feature-abi-rules-added

Most of the cap* patches are around generating and maintaining a list of supported capabilities.
the first 2 caps (cap1 & cap2) introduce new scripts to generate a list of current capabilities and
apparmor-bash related profiles.

# cap1-Generate-CAPABILITIES-in-a-script-due-to-make-4.3.patch

there is a new command under /common
./list_capabilities.sh
# code that generates a list of capabilities
CAP_AUDIT_CONTROL
CAP_AUDIT_READ
CAP_AUDIT_WRITE
...
CAP_CHOWN

# new python script to create vim profiles with
python create-apparmor.vim.py
# generates a new file called apparmor.vim.in

# cap2-parser-Move-to-a-pre-generated-cap_names.h.patch
use a pre-generated list of capabilities so that all capabilities are
supported even when building against older kernels.

The rest of the cap* patches are code cleanup related.

@sli2100 I hope that answers some of the concern about capabilities patches.

I will work on testing the other 3 affected LP's (1988270, 1728130, 1993353).
So a total of 4 Lp's will be addressed.

Please let me know if I/someone else can elaborate on the testing that needs to happen before approval.