I have been using openSUSE Leap so far. Currently 15.6, and there’s the migration to 16.0 on the schedule for near future. Despite some “issues” of Leap 16.0, I am willing to stay with openSUSE in general and Leap especially for this time.
With AppArmor and SELinux it looks like this:
up to Leap 15.6 (including) AppArmor is installed and used as standard (you could choose SELinux if you would like)
from Leap 16.0 and ongoing SELinux is installed and used as standard (you could choose AppArmor if you would like)
when migrating (i.e. upgrading) from 15.6 to 16.0 you can/must choose if you want to stay with or change the model
What is your feedback, notes, hints on this? (I.e. what should I prefer?) TIA!
My plan is to try upgrading first. If I experience major issues, I can try a fresh install then. (I always keep care about backups! )
Yes… One question would be if SELinux does work without any major stoppers. Another would be (and this was my intention in starting this thread), what of AppArmor vs SELinux is “better”? (I have just no idea at all!)
For me, AppArmor has caused the least problems. SELinux is supposed to be the more secure one (supposedly), at the cost of some things breaking and having to troubleshoot it yourself. For instance, gaming requires a separate package, etc.
With SELinux and the openSUSE Leap 16.0 series being around for the next 8 years, roll with it… just like a 2-4GB (I use 4GB) for /boot/efi who knows what the future will spring on the distribution…
Oh, If your on Intel cpu, add intel_iommu=on to the boot options, it adds some additional security, see the output from fwupdmgr security --show-all, the show-all adds links to output information.
Likewise swap, I’ve switched to zram-generator again this offers encrypted swap OTB, again visible with fwupdmgr security.
@asdhio If you install setroubleshoot-server package and use Cockpit, it will provide all the information needed to a) Fix temporarily (if wanted) and b) provide appropriate information for a bug report.
And there is also the setroubleshoot package that provides the same information from setroubleshoot-server in a GUI. I would advise a little caution regarding the suggestions from the tools to fix problems. They are occasionally unreliable.
I used the migration tool to migrate from 15.6 to 16.0 and switched to SELinux on my workstation. Aside from one problem caused by the migration tool, it ran largely without issues after a manual fix. Problems so far have only occurred with packages and software not belonging to the Leap distribution. If you only use Leap 16.0 packages and don’t make larger custom modifications SELinux should work reasonably well.
For the case of my personal experience with SELinux on Leap 16.0 and now on Tumbleweed, there’s a couple of things you have to be aware of –
After every change of anything (patches or updates) in the system directories “restorecon -F -R -v /???” seems to be mandatory …
Take care to be aware of the examples at the end of the “semanage-fcontext” man (8) page.
When first enabling SELinux, or, migrating from Leap to Tumbleweed, in ‘/etc/selinux/config’ use this setting: “SELINUX=permissive” – change it to “enforcing” after you’ve got the system sorted out and running quietly.
Apart from those points, I’m not experiencing anything horrible or nasty with SELinux –
Ignore the suggestions “Cockpit” makes with respect to SELinux – the current openSUSE SELinux policy is, AFAICS, more than sufficient for my desktop – I have absolutely no idea if other people’s desktops will also be OK with the default openSUSE policy.
The openSUSE SELinux policy uses the Fedora SELinux policy as upstream with some openSUSE-specific changes. That means, most documentation for Fedora is also applicable to openSUSE.
A bug report and a possible bug potentially being fixed quite soon sounds better than forcing me to apply that command regularly…
Any people out there experiencing serious problems with SELinux? I ask this under this motivation: I could stay with AppArmor (as it has been now — and working). I would rather choose switching to SELinux as it is set as the new standard (and seems to show quite more confinements generally).
I do not think this is the case, for patches or updates, rpm updates, rpm already stores the correct file contexts and policy packages trigger relabeling where required.
I’ve not had any, did have a hiccup when testing flatpak bottles, but from an OS perspective nothing that has stopped the systems or applications running.
Now I only use default repositories, a few multimedia and chrome flatpaks AND they are just test systems aside from the on-the-road AMD HP Laptop…
@malcolmlewis I don’t get it right: does Flatpak actually work or not? Sorry for this humble question. I would like to know this seriously because I make use of Flatpak (I am dependent in some way… even as I prefer RPM management!).
gunnersson@tulicube:~> flatpak list --app
Name Anwendungskennung Version Zweig Installation
VSCodium com.vscodium.codium 1.107.18627 stable system
XnView MP com.xnview.XnViewMP 1.9.10 stable system
MediathekView de.mediathekview.MediathekView 14.4.2 stable system
Qalculate! (GTK UI) io.github.Qalculate 5.9.0 stable system
Cockpit Client org.cockpit_project.CockpitClient 355 stable system
Gramps org.gramps_project.Gramps 6.0.6 stable system
digiKam org.kde.digikam 8.8.0 stable system
ScummVM org.scummvm.ScummVM 2026.1.0 stable system
gunnersson@tulicube:~>
Yes, for the case of Leap, I moved it over to SELinux and, I was using the latest KDE Plasma version on the Open Build Service – for the case of Tumbleweed, I moved from Leap to Tumbleweed by means of “zypper dup” – there’s a mention in the “How To” pointing to a trigger which causes the security contexts to be reset on the reboot after the upgrade has been executed.
There have been a couple of Tumbleweed updates since I moved over – ‘/usr/’ hasn’t been recording too many incorrect security contexts – ‘/etc/’ and ‘/var/’ and ‘/root/’ all record incorrect security contexts after an update.
Once I’ve settled into the “Tumbleweed world”, I’ll consider raising a Bug Report with concrete evidence.
you’re correct for the packages in the openSUSE “cdn” repositories.
> LANG=C zypper search --installed-only --repo essentials
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------------------------------+---------------------------------------------------------------+--------
i+ | chromium-plugin-widevinecdm | Chromium Widevine CDM plugin | package
i+ | gstreamer-plugins-bad-codecs | Codecs/plugins for gstreamer-plugins-bad | package
i+ | gstreamer-plugins-ugly-codecs | Codecs/plugins for gstreamer-plugins-ugly | package
i | libde265-0 | Open H.265 video codec implementation - libraries | package
i | libfaac0 | Shared library part of faac | package
i | libopenaptx0 | An implementation of Audio Processing Technology codec (aptX) | package
i+ | librtmp1 | RTMP Stream Dumper Library | package
i+ | libx264-165 | A free h264/avc encoder | package
i | libx265-215 | A free H265/HEVC encoder - encoder binary | package
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
>
> LANG=C zypper search --installed-only --repo hardware-tools
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+------+----------------------------------------+--------
i | crda | 802.11 central regulatory domain agent | package
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
>
> LANG=C zypper search --installed-only --repo kde:extra
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-----------------+-----------------------------------------------+--------
i+ | digikam-gmic-qt | Plugins for G'MIC-Qt integration into DigiKam | package
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
>
> LANG=C zypper search --installed-only --repo libdvdcss
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+------------+-------------------------------------------------+--------
i+ | libdvdcss2 | A library designed for accessing encrypted DVDs | package
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
>
> LANG=C zypper search --installed-only --repo php-apps
Loading repository data...
Reading installed packages...
S | Name | Summary | Type
---+-------------------+-----------------------------------------+--------
i+ | drupal7 | Open source content management platform | package
i+ | drupal7-apache | Apache configuration for drupal7 | package
i+ | wordpress | World largest Bloging tool | package
i+ | wordpress-apache | Apache configuration for wordpress | package
i+ | wordpress-plugins | Plugins for wordpress | package
i+ | wordpress-themes | Original Themes for wordpress | package
Note: For an extended search including not yet activated remote resources please use 'zypper
search-packages'.
>
For the case of the Packman repository, the SELinux security contexts are not correct.
For the case of the other openSUSE repositories, including the openh264 repository, I not sure – time will tell …
For the case of ‘/var/’ –
/var/log/updateTestcase-2026-*
/var/lib/sddm/.cache/*
/var/cache/swcatalog/*
/var/cache/ldconfig/aux-cache
/var/cache/man/*
/var/cache/zypp/solv/*
/var/cache/zypp/raw/*
/var/cache/zypp/geoip.d
/var/cache/zypp/geoip.d/download.opensuse.org
all have to relabeled after an update.
For the case of ‘/etc/’ –
Relabeled /etc/ld.so.cache from unconfined_u:object_r:etc_t:s0 to system_u:object_r:ld_so_cache_t:s0
For the case of ‘/root/’ – the files I create with “| tee” from the restorecon output:
Relabeled /root/SELinux_policy_2026-02-16-10:23_root from unconfined_u:object_r:admin_home_t:s0 to system_u:object_r:admin_home_t:s0
)