
On Mon, Jul 22, 2024 at 8:48 AM Dominique Leuenberger <dimstar@opensuse.org> wrote:
On Mon, 2024-07-22 at 09:28 +0200, Jiri Slaby wrote:
On Fri, 2024-07-19 at 11:24 -0400, Neal Gompa wrote:
On Fri, Jul 19, 2024 at 10:28 AM Cathy Hu <cahu@suse.de> wrote:
I'm excited about this change, personally. :)
yay :)
Does this mean the kernel config will change so that CONFIG_DEFAULT_SECURITY_SELINUX=y will be set instead of CONFIG_DEFAULT_SECURITY_APPARMOR=y? That is, I don't need to set "selinux=1" in the kernel commandline anymore for new setups? I would really like that to be included in this change...
So far our plan is that we will *not* change the kernel config. We will only change the default MAC setting in the installer to SELinux. The installer will then take care of setting the kernel command line in your bootloader for you, so no need to manually set selinux=1 then.
Hope that helps, let me know if it doesn't :)
Is this at least happening for the SFO/ALP kernels? Eventually I'd like to see this in Tumbleweed too.
Regardless, a bunch of us are using configurations of openSUSE not made by an installer, so having these defaults handled in the kconfig ensures the right things happen out of the box for first party, second party, and third party folks.
To be honest, I don't test our default config, as I set security=selinux selinux=1 on all my test systems.
So I'm definitely NOT against switching the default to selinux...
In my opinion, we should at least try and see what breaks (in openQA, on users' side). We will have to do it once in the future anyway. Who does deliberately use apparmor these days anyway?
thanks,
How will all existing systems with enabled/maintained AA profiles react to that default change? So far, selinux needed to be explicitly enabled (security=selinux selinux-1)
Unless users would have security-apparmor in their kernel cmdline, they'd be switching to SELinux - having as catastrophic side-effects as systems 'working', but all confinement policies the users had in place not being used (leaving the user in a state where they trust their AA- policies, even though they are not active)
Don't misunderstand me: I do support the switch to SELinux by default, as it is perfectly in line with the Factory First Policy and SELinux is where most resources are these days. Just genuinely worried about userss that went beyond the 'trust the default aa settings or, in case of trouble, disabled it on first impact' (See e.g. Darix' reply on this thread. He, for one, is a very active AA user wihtout much chance to ever migrate to SELinux).
I think we could come up with a migration package to handle this, including switching around kernel arguments on existing systems to ensure existing AA systems stay with AA as the kconfig defaults change. I can help with that. :) -- 真実はいつも一つ!/ Always, there's only one truth!