Feel free to submit it Christian, AppArmor won't be in SLES so we have quite flexibility here.

As of today as much as I don't like it Kernel engineering is evaluating whether to drop AppArmor or not. We could very much use any usecases for it.

We did already shared feedback with Both Engineering team and PM that we have an active AppArmor community in openSUSE. However kernel team claims insufficient resources for maintaining both SELinux and AppArmor parts in kernel.

A usage category that AFAIK is impossible to do with SELinux is privilege separation inside a program, for example

• separating virtual hosts in Apache so that vhost_A can't access data of vhost_B (using mod_apparmor)
• same for php-fpm
• separating mailboxes or domains in dovecot depending on the logged in user so that a logged-in user can't access data from another mailbox even if they manage to exploit a dovecot bug

Also, we have the Samba profile which gets auto-updated based on the smb.conf - and this profile has already prevented at least one Samba exploit in the past.

Personally, I heavily use mod_apparmor which has saved me from problems several times when someone had an outdated and insecure PHP software on my server. I also use the separation in dovecot on a domain level.

Apache mod_apparmor is also used in the openSUSE infrastructure, and for example ensures that the wikis stay clearly separated.

I also have a few "special" profiles, the most special one is probably used for my backup: I allow my backup server to login (via ssh) as root and to run rsync - but restrict that login to reading all files. Write access or executing random binaries gets denied by AppArmor. This means the backup server can do its job, but can't modify anything despite having root access.

Oh, and on my laptop I use the profiles from the apparmor.d project - which means I have nearly 1700 profiles, and most of my running processes (including most of KDE Plasma) are confined.

So much for my usecases.

Besides that, AppArmor profiles are much easier to create and maintain than the SELinux policy IMHO.

Let me also add a question: How much effort does the kernel team have to spend for AppArmor?

The reason why I ask: I just checked the kernel-source packages in Leap 15.6 and Tumbleweed. The kernel changelog in Tumbleweed contains a small amount of AppArmor patches (15-20 lines per year matching "apparmor"). series.conf for Tumbleweed doesn't include any AppArmor patches, and in 15.6:Update series.conf contains 11 AppArmor patches - which is nothing compared to the >20k patches in total. I seriously hope the 11 patches aren't overloading the kernel team...

A usage category that AFAIK is impossible to do with SELinux is privilege separation inside a program, for example

• separating virtual hosts in Apache so that vhost_A can't access data of vhost_B (using mod_apparmor)
• same for php-fpm
• separating mailboxes or domains in dovecot depending on the logged in user so that a logged-in user can't access data from another mailbox even if they manage to exploit a dovecot bug
  

These are all possible with SELinux too. In fact the features to do this is the basis for virtual machine and container sandboxing. It's part of SELinux multi-category security (MCS). There is also a mod_selinux Apache HTTPD module for similar purpose to mod_apparmor.

and yet there is a Fedora Gaming Fork known as nobara, which switched to AA from selinux - because profiles are easier to maintain.

not everyone wants selinux. so we shouldn't just break things.

I fully agree, I can't however give kernel team extra resources. I don't see any final decision anywhere

however I have seen this commit linked to relevant jira
https://github.com/openSUSE/kernel-source/commit/b74aeb04cd428f4a3349c463933b21a503b5002f

Not sure what everything is affected by it.

Related discussion
https://lists.opensuse.org/archives/list/factory@lists.opensuse.org/message/C5X6DLOTUCC5ILCFS3CB6UUPWA2HDOPW/

Keeping open for any related documentation tasks for manual enablement of apparmor (kernel options, pattern installation), release notes etc.

Otherwise the current state as it is, is basically final.

AppArmor 4.1 was released later than expected, but still in time :-)

https://build.opensuse.org/requests/1268897 submitted

I tried to submit AppArmor 4.1.1 with https://build.opensuse.org/request/show/1288381, but it was auto-declined:

Please create a new feature request https://code.opensuse.org/leap/features/issues for updating apparmor from SLFO (SLES, SL Micro). Alternatively, please provide a reason for forking and rebuilding an existing SLFO package in Leap.

So - can you please submit 4.1.1 to SLFO?