Spec URL: https://copr-dist-git.fedorainfracloud.org/packages/rlee287/apparmor/libapparmor.git/tree/libapparmor.spec?id=fab1ac10c033828174f74fb80d823de0d44d4760 SRPM URL: https://download.copr.fedorainfracloud.org/results/rlee287/apparmor/fedora-rawhide-x86_64/09726014-libapparmor/libapparmor-4.1.2-1.fc44.src.rpm Description: This package provides a libapparmor library one can compile programs against in order to use various AppArmor functionality, such as transitioning to a different AppArmor profile or hat. Fedora Account System Username: rlee287 As an upstream maintainer of the AppArmor project, we are interested in introducing the option of using the AppArmor LSM to Fedora. While Fedora currently uses SELinux, there is also at least one Fedora-drived distro (e.g. Nobara) that uses AppArmor. Moreover, once LSM stacking becomes available in the kernel, it would also be useful to allow AppArmor and SELinux to be used simultaneously. Later steps in enabling this integration will include packaging up the entirety of AppArmor (not just libapparmor), along with enabling AppArmor support in other programs like systemd. As a first step, however, I am requesting the packaging of just libapparmor first in order to gain experience with Fedora packaging (which I adapted from the openSUSE packaging) before submitting a request for the rest of the AppArmor userspace. COPR build results are available at https://copr.fedorainfracloud.org/coprs/rlee287/apparmor/build/9726014/ . This is my first time uploading and creating a package for Fedora, so I'll need a sponsor to review and approve the packaging.
Copr build: https://copr.fedorainfracloud.org/coprs/build/9726417 (succeeded) Review template: https://download.copr.fedorainfracloud.org/results/@fedora-review/fedora-review-2406130-libapparmor/fedora-rawhide-x86_64/09726417-libapparmor/fedora-review/review.txt Please take a look if any issues were found. --- This comment was created by the fedora-review-service https://github.com/FrostyX/fedora-review-service If you want to trigger a new Copr build, add a comment containing new Spec and SRPM URLs or [fedora-review-service-build] string.
Taking this review.
This whole spec probably should be rewritten. Even the openSUSE spec is slightly bad here. Initial notes: * The source package name should be "apparmor", not "libapparmor". * The python bcond should be dropped, there is no case where it would be disabled * We do not follow openSUSE SLPP, so the library subpackage would be "libapparmor" * Group tag lines need to be deleted * Zypp-specific weird split Provides need to be deleted * Subpackage interdependencies need to be tightened to "= %{version}-%{release}" rather than the weaker "= %{version}" * Superfluous Requires on python3 should be dropped Additionally, I'm pretty sure the apparmor source package provides quite a lot more than just libapparmor, you should endeavor to build out everything from the source package that you can. However, let me address this one point: > Moreover, once LSM stacking becomes available in the kernel, it would also be useful to allow AppArmor and SELinux to be used simultaneously. It is extremely unlikely we will enable AppArmor in Fedora for LSM stacking. Getting the policies to work properly with both will be a nightmare and it is not worth the pain.
Hey Neal, thank you for taking the review. One point on LSM stacking. This will be very useful for one other reason: it would allow running apparmor policy inside a container. A Fedora system can then load vanilla Debian container and with stacking enabled, do the usual podman selinux MCS setup, and with an apparmor namespace in the container, load policies that would apply regular Debian apparmor behaviour for the workload running there. My point is that this is not about putting AppArmor policy on top of fedora, but having the tools available so that containerised workloads can benefit from stronger security. By the nature of LSM stacking, the whole stack has to agree for something to be effectively allowed. Given how poor MCS security is inside a typical podman container (everything is just flat there, per container), it would provide meaningful improvement without any complexity on the host.