RFC: SELinux as default MAC system on new Tumbleweed installations
Hi all, *see TL;DR down below* SELinux is being adopted more and more as the main Mandatory Access Control (MAC) system in openSUSE distributions and SUSE products. The SUSE SELinux working group would like to announce the plan to switch new Tumbleweed installations to SELinux as default MAC system *by the end of this year*. Currently, new Tumbleweed installations select AppArmor in the installer as default MAC system. After this change, new Tumbleweed installations will select SELinux in enforcing mode as default MAC system. Users will still be able to select AppArmor as MAC system in the installer. Existing installations will *not* be affected. If you would like to migrate your existing system from AppArmor to SELinux, we have a guide on what to consider and how to do that here [0]. *What does it mean for users?* Our SELinux policy contains many policy modules, which confine most well-known services. Switching to SELinux means more services are confined by default, which means enhanced security. On the other hand, more confinement also means that in the early phase of the adoption there could be more bugs caused by SELinux denying legitimate accesses. We perform both manual and automated tests via openQA, to ensure that our policy works seamlessly. We also rely on you, the community, to create bugreports so that we can adapt the policy to any scenarios that we did not foresee. We have a page on how to report bugs here: https://en.opensuse.org/openSUSE:Bugreport_SELinux To learn more about SELinux, we also have a Portal in the openSUSE wiki: https://en.opensuse.org/Portal:SELinux Please feel free to reply to this email in case you have any questions or concerns. We plan to do the change earliest in September 2024, and latest by the end of the year. Separate announcements will follow just before and after the change. TL;DR: - The Tumbleweed installer will select SELinux in enforcing mode as default on new installations - When: by the end of 2024, earliest in September, we will do separate announcements before and after - AppArmor can still be selected in the installer as an alternative - Existing installations will *not* change - Leap 15.x is not affected in any way Thank you very much :) Kind regards, Cathy [0] https://en.opensuse.org/Portal:SELinux/Setup#Setup_SELinux_on_existing_tumbl... -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Fri, Jul 19, 2024 at 2:45 AM Cathy Hu <cahu@suse.de> wrote:
Hi all,
*see TL;DR down below*
SELinux is being adopted more and more as the main Mandatory Access Control (MAC) system in openSUSE distributions and SUSE products. The SUSE SELinux working group would like to announce the plan to switch new Tumbleweed installations to SELinux as default MAC system *by the end of this year*.
Currently, new Tumbleweed installations select AppArmor in the installer as default MAC system. After this change, new Tumbleweed installations will select SELinux in enforcing mode as default MAC system. Users will still be able to select AppArmor as MAC system in the installer.
Existing installations will *not* be affected. If you would like to migrate your existing system from AppArmor to SELinux, we have a guide on what to consider and how to do that here [0].
*What does it mean for users?* Our SELinux policy contains many policy modules, which confine most well-known services. Switching to SELinux means more services are confined by default, which means enhanced security. On the other hand, more confinement also means that in the early phase of the adoption there could be more bugs caused by SELinux denying legitimate accesses.
We perform both manual and automated tests via openQA, to ensure that our policy works seamlessly. We also rely on you, the community, to create bugreports so that we can adapt the policy to any scenarios that we did not foresee. We have a page on how to report bugs here: https://en.opensuse.org/openSUSE:Bugreport_SELinux
To learn more about SELinux, we also have a Portal in the openSUSE wiki: https://en.opensuse.org/Portal:SELinux
Please feel free to reply to this email in case you have any questions or concerns. We plan to do the change earliest in September 2024, and latest by the end of the year. Separate announcements will follow just before and after the change.
TL;DR: - The Tumbleweed installer will select SELinux in enforcing mode as default on new installations - When: by the end of 2024, earliest in September, we will do separate announcements before and after - AppArmor can still be selected in the installer as an alternative - Existing installations will *not* change - Leap 15.x is not affected in any way
Thank you very much :)
Kind regards,
Cathy
[0] https://en.opensuse.org/Portal:SELinux/Setup#Setup_SELinux_on_existing_tumbl...
I'm excited about this change, personally. :) 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... -- 真実はいつも一つ！/ Always, there's only one truth!
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 :)
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. -- 真実はいつも一つ！/ Always, there's only one truth!
I will have to ask the kernel team what they think about that and if we can consider that, adding Jiri to the thread as the tumbleweed kernel maintainer and the kernel mailing list for SLFO. For SLFO/ALP, this is not set yet as far as I can see (I might be wrong, I'm not a kernel dev) https://github.com/openSUSE/kernel-source/blob/ALP-current/config/x86_64/def... @kernel peoples, what do you think? Thanks :) 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.
-- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 22. 07. 24, 9:15, Cathy Hu wrote:
I will have to ask the kernel team what they think about that and if we can consider that, adding Jiri to the thread as the tumbleweed kernel maintainer and the kernel mailing list for SLFO.
For SLFO/ALP, this is not set yet as far as I can see (I might be wrong, I'm not a kernel dev) https://github.com/openSUSE/kernel-source/blob/ALP-current/config/x86_64/def...
@kernel peoples, what do you think?
Thanks :)
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, -- js suse labs
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). Cheers, Dominique
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!
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. :)
To avoid risk of breakage due to multiple changes at once, I would rather not change the kernel config in tumbleweed at this time. Lets focus on the installer change first, see what happens and after that is done smoothly, we can have a look at other tweaking other stuff. -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 24. 07. 24, 8:04, Cathy Hu wrote:
To avoid risk of breakage due to multiple changes at once, I would rather not change the kernel config in tumbleweed at this time.
Lets focus on the installer change first, see what happens and after that is done smoothly, we can have a look at other tweaking other stuff.
Sounds reasonable from my POV. thanks, -- js suse labs
Am 22.07.24 um 14:55 schrieb Neal Gompa:
On Mon, Jul 22, 2024 at 8:48 AM Dominique Leuenberger <dimstar@opensuse.org> wrote:
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.
any defaults for non-essential (and potentially breaking old installs) stuff like that in the kernel config seems awkward to me, even the current apparmor default should not be there IMVHO (maybe it is required to have one module as default, no idea), but probably cannot be removed in order to not break old systems. I mean we also do not hard code the root device via "rdev" since quite some time in the kernel image ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Just a heads up, several emails in this thread are getting caught up in the moderation queue for having more then 10 recipients, so its probably worth avoiding reply to all here. On 7/20/24 12:54 AM, 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.
-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 7/19/24 8:45 AM, Cathy Hu wrote:
Hi all,
*see TL;DR down below*
SELinux is being adopted more and more as the main Mandatory Access Control (MAC) system in openSUSE distributions and SUSE products. The SUSE SELinux working group would like to announce the plan to switch new Tumbleweed installations to SELinux as default MAC system *by the end of this year*.
Hi, I read https://en.opensuse.org/Portal:SELinux/PackagingCustomPolicy. Are there some common practices for packages one wants to ship both an AppArmor profile and a custom SELinux policy module with? Best, Georg
I read https://en.opensuse.org/Portal:SELinux/PackagingCustomPolicy. Are there some common practices for packages one wants to ship both an AppArmor profile and a custom SELinux policy module with?
Good question! We currently do not have many packages that ship both I think. From the top of my mind there forgejo [0] and passt [1], which do it differently. My personal preference would be the way that forgejo does it. That means, the custom SELinux modules should be in a subpackage called <package>-selinux and custom AppArmor profiles should be in a subpackage <package>-apparmor, e.g: <package>-apparmor <package>-selinux And in the main package, you can `Require` the subpackage depending if the main apparmor or selinux packages are installed on the system. For example like this (from forgejo spec file): Requires: (%{name}-apparmor if apparmor-abstractions) Requires: (%{name}-selinux if selinux-policy-targeted) However, I am also open to other ways and ideas to do it. Custom SELinux modules outside the main selinux-policy package have not been something really common so far and packages shipping both are even less common. Most of the SELinux modules are currently in our main selinux- policy [2] package. Hope that helps, let me know if not :D [0] https://build.opensuse.org/package/show/openSUSE:Factory/forgejo [1] https://build.opensuse.org/package/show/openSUSE:Factory/passt [2]https://build.opensuse.org/package/show/openSUSE:Factory/selinux-policy
As the maintainer of forgejo, I would also love to know about how we should do this. I don't mind changing how I package forgejo. Was also debating about abolishing apparmor, as I am already on selinux, and "recently" noticed that the apparmor profile had a mistake in it, which made it unusable. But as nobody complained, I can almost assume that nobody uses it anyway. On 19/07/2024 17:39, Cathy Hu wrote:
I read https://en.opensuse.org/Portal:SELinux/PackagingCustomPolicy. Are there some common practices for packages one wants to ship both an AppArmor profile and a custom SELinux policy module with?
Good question! We currently do not have many packages that ship both I think. From the top of my mind there forgejo [0] and passt [1], which do it differently.
My personal preference would be the way that forgejo does it. That means, the custom SELinux modules should be in a subpackage called <package>-selinux and custom AppArmor profiles should be in a subpackage <package>-apparmor, e.g:
<package>-apparmor <package>-selinux
And in the main package, you can `Require` the subpackage depending if the main apparmor or selinux packages are installed on the system.
For example like this (from forgejo spec file): Requires: (%{name}-apparmor if apparmor-abstractions) Requires: (%{name}-selinux if selinux-policy-targeted)
However, I am also open to other ways and ideas to do it. Custom SELinux modules outside the main selinux-policy package have not been something really common so far and packages shipping both are even less common. Most of the SELinux modules are currently in our main selinux- policy [2] package.
Hope that helps, let me know if not :D
[0] https://build.opensuse.org/package/show/openSUSE:Factory/forgejo [1] https://build.opensuse.org/package/show/openSUSE:Factory/passt [2]https://build.opensuse.org/package/show/openSUSE:Factory/selinux-policy
As the maintainer of forgejo, I would also love to know about how we should do this. I don't mind changing how I package forgejo. Was also debating about abolishing apparmor, as I am already on selinux, and "recently" noticed that the apparmor profile had a mistake in it, which made it unusable. But as nobody complained, I can almost assume that nobody uses it anyway.
After some discussions with the team, I added to the wiki page that we strongly advise to talk to us to get your custom module added to the main selinux-policy package [0]. So that means for the forgejo specifically, if you would like to get the selinux policy module added to the main policy, please drop us an email privately and we can discuss this. For the general AppArmor + SELinux custom module in the same package, if would really like to ship both (not advised), you can use the way as described in my previous email :) [0] https://build.opensuse.org/package/show/openSUSE:Factory/selinux-policy -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On 19.07.2024 18:39, Cathy Hu wrote:
I read https://en.opensuse.org/Portal:SELinux/PackagingCustomPolicy. Are there some common practices for packages one wants to ship both an AppArmor profile and a custom SELinux policy module with?
Good question! We currently do not have many packages that ship both I think. From the top of my mind there forgejo [0] and passt [1], which do it differently.
My personal preference would be the way that forgejo does it. That means, the custom SELinux modules should be in a subpackage called <package>-selinux and custom AppArmor profiles should be in a subpackage <package>-apparmor, e.g:
<package>-apparmor <package>-selinux
Now I am genuinely surprised. Packages are not allowed to install systemd unit presets, packages are now allowed to install polkit rules, packages are not allowed to install custom /etc/permissions, but packages are allowed to install custom MAC profiles? I was sure that any AppArmor/SELinux changes must go in via the single package after security review. Am I wrong?
And in the main package, you can `Require` the subpackage depending if the main apparmor or selinux packages are installed on the system.
For example like this (from forgejo spec file): Requires: (%{name}-apparmor if apparmor-abstractions) Requires: (%{name}-selinux if selinux-policy-targeted)
However, I am also open to other ways and ideas to do it. Custom SELinux modules outside the main selinux-policy package have not been something really common so far and packages shipping both are even less common. Most of the SELinux modules are currently in our main selinux- policy [2] package.
Hope that helps, let me know if not :D
[0] https://build.opensuse.org/package/show/openSUSE:Factory/forgejo [1] https://build.opensuse.org/package/show/openSUSE:Factory/passt [2]https://build.opensuse.org/package/show/openSUSE:Factory/selinux-policy
Now I am genuinely surprised. Packages are not allowed to install systemd unit presets, packages are now allowed to install polkit rules, packages are not allowed to install custom /etc/permissions, but packages are allowed to install custom MAC profiles?
I was sure that any AppArmor/SELinux changes must go in via the single package after security review. Am I wrong?
Currently this is not the case for custom SELinux modules, but you are right, thanks for pointing that out. As MAC is an additional layer of security, it is not as detrimental as a package shipping with issues in their polkit rules/pam/systemd unit presets/.. or the other stuff that is monitored, which could lead to privilege escalation immediately. However, I agree that custom SELinux modules should be monitored. I will talk to the other people in the security team if we can get this into rpmlint or some other monitoring and perform reviews on submissions. I will create a wiki page on submission guidelines / review process when I know more. Thanks a lot for the pointer :) -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
However, I agree that custom SELinux modules should be monitored. I will talk to the other people in the security team if we can get this into rpmlint or some other monitoring and perform reviews on submissions.
I will create a wiki page on submission guidelines / review process when I know more.
So, I talked to the others and we agreed that we will implement passive monitoring for the custom SELinux modules and contact people directly if something is really wrong. So from the packager's side, just submit as usual and unless you hear something from us, you're fine. -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
as long as you dont break AppArmor as it happened on other distributions I am fine. My highly granular AppArmor profiles can not be ported to selinux. Nor have I seen how to implement selinux scopes per php-fpm pool yet. While there are 1-2 features from selinux, where I wished apparmor had them (mostly secmark for firewall rules. so i can ensure only protected apps can talk to the network) currently selinux is no AA replacement for me. also I found it funny that a fedora flavor for gaming did this: 5. I heard Nobara breaks SELinux, is this true? – No. We have completely swapped SELinux in favor of AppArmor (this is what Ubuntu and OpenSUSE use). We find AppArmor to be more user friendly, less intrusive, and easier to manage and write policies for. You will still see some SELinux packages installed which are required to keep Fedora compatibility and not break package dependencies, but SELinux is otherwise disabled. So please keep AA alive -- Always remember: Never accept the world as it appears to be. Dare to see it for what it could be. The world can always use more heroes.
So please keep AA alive
We don't intend to change anything in AppArmor (I can't btw, I am not the maintainer :)). We will just change the default in the installer, please feel free to select AppArmor on new installations if you prefer it over SELinux. -- Cathy Hu <cahu@suse.de> SELinux Security Engineer GPG: 5873 CFD1 8C0E A6D4 9CBB F6C4 062A 1016 1505 A08A SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
On Mon, Jul 22, 2024 at 09:50:47AM +0200, Cathy Hu wrote:
So please keep AA alive
We don't intend to change anything in AppArmor (I can't btw, I am not the maintainer :)). We will just change the default in the installer, please feel free to select AppArmor on new installations if you prefer it over SELinux.
Just to make sure that this is fully understood: How AA support is handled is not something we (on the SELinux side) decide. There were discussions within SUSE to drop AA support, as it would be dead code for us going forward. I'm not a fan of the idea, as people should be free to chose in my opinion. But if this happens or not is decided by people that manage the products. And on the openSUSE side this also is depending on the project leadership keeping AA support. Johannes -- GPG Key EE16 6BCE AD56 E034 BFB3 3ADD 7BF7 29D5 E7C8 1FA0 Subkey fingerprint: 250F 43F5 F7CE 6F1E 9C59 4F95 BC27 DD9D 2CC4 FD66 SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nürnberg, Germany Geschäftsführer: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB 36809, AG Nürnberg)
Hello, Am Montag, 22. Juli 2024, 16:20:49 MESZ schrieb Johannes Segitz:
Just to make sure that this is fully understood: How AA support is handled is not something we (on the SELinux side) decide. There were discussions within SUSE to drop AA support, as it would be dead code for us going forward. I'm not a fan of the idea, as people should be free to chose in my opinion. But if this happens or not is decided by people that manage the products. And on the openSUSE side this also is depending on the project leadership keeping AA support.
I heavily rely on AppArmor, and I slightly ;-) doubt that SELinux would be a good and/or more secure replacement for the > 1200 profiles I use [1]. This also means that I'll continue to maintain the AppArmor package and my upstream contributions. As usual, I'll also help people if they need support with creating profiles, or just want a profile review. Sometimes you'll even get a "surprise review" if I notice something in a profile your package ships ;-) Regards, Christian Boltz [1] lots of them from the apparmor.d project, packaged in home:cboltz (still packaged in complain mode, but that will probably change soon). In case you wonder - a SR to that package some months ago confirmed that I'm not the only user ;-) -- Computers are really easy. There is just Zero and One, and it does not get any more complicated than that. [https://blog.koehntopp.info/2022/05/03/fertig-gelesen-the-pattern-on-the-sto...]
On Mon, 22 Jul 2024 16:20:49 +0200 Johannes Segitz <jsegitz@suse.de> wrote:
On Mon, Jul 22, 2024 at 09:50:47AM +0200, Cathy Hu wrote:
So please keep AA alive
We don't intend to change anything in AppArmor (I can't btw, I am not the maintainer :)). We will just change the default in the installer, please feel free to select AppArmor on new installations if you prefer it over SELinux.
Just to make sure that this is fully understood: How AA support is handled is not something we (on the SELinux side) decide. There were discussions within SUSE to drop AA support, as it would be dead code for us going forward. I'm not a fan of the idea, as people should be free to chose in my opinion. But if this happens or not is decided by people that manage the products. And on the openSUSE side this also is depending on the project leadership keeping AA support.
Hi, I am just curious who manage the Tumbleweed product? I know that it is do-ocracy, but I am not sure if it works well for product decisions like what to support, what will be default, etc. I would really like to see some steering committee that is entrusted to do such decision, as for installer it will be much easier to have counterpart to ask/discuss product decisions (e.g. also to help new users with pre-selected DE whatever will be ). Josef P.S. I am not against this change and have nothing against SELinux nor AppArmor, just not sure how exactly works decision making for TW ( and sometimes even Leap ).
Johannes
On Fri, 2024-07-26 at 09:37 +0200, josef Reidinger wrote:
Hi, I am just curious who manage the Tumbleweed product? I know that it is do-ocracy, but I am not sure if it works well for product decisions like what to support, what will be default, etc. I would really like to see some steering committee that is entrusted to do such decision, as for installer it will be much easier to have counterpart to ask/discuss product decisions (e.g. also to help new users with pre-selected DE whatever will be ).
Unpopular opinion - but I'd say my team (SUSELabs/Early Adopters) 'owns' the final decisions on the openSUSE Tumbleweed and Leap products. Certainly we try to only act as 'supporting body' for things the community submits and are always happy not having to 'decide for or against' a feature. Whenever people do work to move something, we rather point out technical conflicts; like in the SELinux switch, the 'migration' to the new default will be the tricky/impossible part. There is a weekly "Release Engineering" meeting where aspects for Tumbleweed/Leap/MicroOS/Aeon are being discussed. https://calendar.opensuse.org/teams/release/events/opensuse-release-engineer... Meeting minutes are being published weekly to the mailing lists and are kept for reference on etherpad. Cheers, Dominique
On Fri, 26 Jul 2024 09:48:58 +0200 Dominique Leuenberger <dimstar@opensuse.org> wrote:
On Fri, 2024-07-26 at 09:37 +0200, josef Reidinger wrote:
Hi, I am just curious who manage the Tumbleweed product? I know that it is do-ocracy, but I am not sure if it works well for product decisions like what to support, what will be default, etc. I would really like to see some steering committee that is entrusted to do such decision, as for installer it will be much easier to have counterpart to ask/discuss product decisions (e.g. also to help new users with pre-selected DE whatever will be ).
Unpopular opinion - but I'd say my team (SUSELabs/Early Adopters) 'owns' the final decisions on the openSUSE Tumbleweed and Leap products. Certainly we try to only act as 'supporting body' for things the community submits and are always happy not having to 'decide for or against' a feature. Whenever people do work to move something, we rather point out technical conflicts; like in the SELinux switch, the 'migration' to the new default will be the tricky/impossible part.
So it will mean that technically TW/Leap is driven by one of SUSE team. That is for me problematic from two points. The first one is that Early Adopters team is basically playground for new technologies for SUSE products, which I am not sure is not always in conflict with users/community interest. And the second reason is that it is not anyway formalized, so I do not expect many people know it ( including me ), that they should contact your team for such decisions ( is it even publicly available who is responsible for what and who is in team? ). For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
There is a weekly "Release Engineering" meeting where aspects for Tumbleweed/Leap/MicroOS/Aeon are being discussed.
https://calendar.opensuse.org/teams/release/events/opensuse-release-engineer...
Meeting minutes are being published weekly to the mailing lists and are kept for reference on etherpad.
I kind of expect that Release Engineering is more about topics regarding issues with releasing product, not about technical directions of product.
Cheers, Dominique
Josef
On Fri, 2024-07-26 at 11:00 +0200, josef Reidinger wrote:
So it will mean that technically TW/Leap is driven by one of SUSE team. That is for me problematic from two points. The first one is that Early Adopters team is basically playground for new technologies for SUSE products, which I am not sure is not always in conflict with users/community interest. And the second reason is that it is not anyway formalized, so I do not expect many people know it ( including me ), that they should contact your team for such decisions ( is it even publicly available who is responsible for what and who is in team? ). For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
You confuse my team with Thorsten's Team: Future Technologies. Tumbleweed has always been, and should always remain, 'open to new technlogogies' (you can call it playground) for as long as it does not break stuff immediately (break down the line when the new tech has become standard is sometimes inevitable, e.g sysv -> systemd) Conflict is the nature of people interacting. Always has happened, always will happen. The team formally responsible for all Leap and Tumbleweed releases is listed at https://en.opensuse.org/openSUSE:Release_team """ The team also tries to facilitate and take decisions regarding the direction and well being of the openSUSE distributions. """
There is a weekly "Release Engineering" meeting where aspects for Tumbleweed/Leap/MicroOS/Aeon are being discussed.
https://calendar.opensuse.org/teams/release/events/opensuse-release-engineer...
Meeting minutes are being published weekly to the mailing lists and are kept for reference on etherpad.
I kind of expect that Release Engineering is more about topics regarding issues with releasing product, not about technical directions of product.
We are too good to have technical problems every week :) Large scale changes (like AppArmor -> SELinux switch just recently proposed) are always redirected to the factory mailing list, where people are welcome to participate and give their feedback. Based on that (minus trolls) the RelEng team will loop back with the original proposal to move forward (or not). The model seems to have worked reliably well so far. Of course there is always room for improvement, but considering that things like Aeon and Kalpa could come out, or initiatives like Slowroll, seems to indicate that people seem to find their ways around 'somehow' Cheers, Dominique
On Fri, 26 Jul 2024 13:07:39 +0200 Dominique Leuenberger <dimstar@opensuse.org> wrote:
On Fri, 2024-07-26 at 11:00 +0200, josef Reidinger wrote:
So it will mean that technically TW/Leap is driven by one of SUSE team. That is for me problematic from two points. The first one is that Early Adopters team is basically playground for new technologies for SUSE products, which I am not sure is not always in conflict with users/community interest. And the second reason is that it is not anyway formalized, so I do not expect many people know it ( including me ), that they should contact your team for such decisions ( is it even publicly available who is responsible for what and who is in team? ). For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
You confuse my team with Thorsten's Team: Future Technologies.
Tumbleweed has always been, and should always remain, 'open to new technlogogies' (you can call it playground) for as long as it does not break stuff immediately (break down the line when the new tech has become standard is sometimes inevitable, e.g sysv -> systemd)
Conflict is the nature of people interacting. Always has happened, always will happen.
The team formally responsible for all Leap and Tumbleweed releases is listed at https://en.opensuse.org/openSUSE:Release_team
""" The team also tries to facilitate and take decisions regarding the direction and well being of the openSUSE distributions. """
There is a weekly "Release Engineering" meeting where aspects for Tumbleweed/Leap/MicroOS/Aeon are being discussed.
https://calendar.opensuse.org/teams/release/events/opensuse-release-engineer...
Meeting minutes are being published weekly to the mailing lists and are kept for reference on etherpad.
I kind of expect that Release Engineering is more about topics regarding issues with releasing product, not about technical directions of product.
We are too good to have technical problems every week :)
Large scale changes (like AppArmor -> SELinux switch just recently proposed) are always redirected to the factory mailing list, where people are welcome to participate and give their feedback. Based on that (minus trolls) the RelEng team will loop back with the original proposal to move forward (or not).
The model seems to have worked reliably well so far. Of course there is always room for improvement, but considering that things like Aeon and Kalpa could come out, or initiatives like Slowroll, seems to indicate that people seem to find their ways around 'somehow'
Cheers, Dominique
Do not get me wrong, I do not blame your work as result of it I am happily using everyday. I just thing that this model basically means that openSUSE ( or whatever new name is used ) is not community distribution based on SUSE source codes ( for leap case ) or with SUSE as major contributor ( for TW ), but it is more SUSE driven free distribution with community support. So maybe we should somehow distinguish it that TW and Leap is SUSE driven and stuff like Aeon is not officially SUSE driven. In this light I have to say that I really support Jeff idea to do beside openSUSE rename also governance change that allows more community engagement. Josef
On 2024-07-26 11:00, josef Reidinger wrote:
For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
Firstly, I'd like to say that I trust Dominique's Early Adopters team to steward Tumbleweed better than any other alternative. I think deciding a default desktop for Tumbleweed or Leap is highly problematic: - Both are general purpose distributions that could be Desktops, or Servers, or anything else - Both offer multiple desktops with vibrant volunteer communities actively supporting them I wholly agree that those above points can make Tumbleweed or Leap more intimidating to new users. But I think elevating a single Desktop role to a default at the expense of the rest of the community (contributors & users) who use those distributions for other things, actually hurts more than it helps. I think it's better for Tumbleweed and Leap to lead into the flexibility and excessive choice they offer. I also think this is better aligned with the realities of the Installers available for those distributions also. YaST historically has been very limited in it's ability to hide/remove options from users, which is precisely something that _needs_ to be done if the goal is to "avoid unnecessary confusion for people coming from windows or mac world" Agama currently seems to make that even worse, with it being necessary for someone to pick from a collection of different "Products/Distributions" first. My request to make it possible to streamline Agama's workflow has not been replied to in over a year: https://github.com/openSUSE/agama/issues/601 Meanwhile this Project now does have offerings like Aeon (using it's own installer) which offer a more focused, single Desktop, single purpose approach which I think is a far better approach for people coming from the Windows or Mac World. I think that's a better way of addressing the problem rather than ruining what makes Tumbleweed awesome.
On Fri, Jul 26, 2024 at 7:55 AM Richard Brown <rbrown@suse.de> wrote:
On 2024-07-26 11:00, josef Reidinger wrote:
For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
Firstly, I'd like to say that I trust Dominique's Early Adopters team to steward Tumbleweed better than any other alternative.
I think deciding a default desktop for Tumbleweed or Leap is highly problematic:
- Both are general purpose distributions that could be Desktops, or Servers, or anything else - Both offer multiple desktops with vibrant volunteer communities actively supporting them
I wholly agree that those above points can make Tumbleweed or Leap more intimidating to new users. But I think elevating a single Desktop role to a default at the expense of the rest of the community (contributors & users) who use those distributions for other things, actually hurts more than it helps.
I think it's better for Tumbleweed and Leap to lead into the flexibility and excessive choice they offer. I also think this is better aligned with the realities of the Installers available for those distributions also. YaST historically has been very limited in it's ability to hide/remove options from users, which is precisely something that _needs_ to be done if the goal is to "avoid unnecessary confusion for people coming from windows or mac world" Agama currently seems to make that even worse, with it being necessary for someone to pick from a collection of different "Products/Distributions" first. My request to make it possible to streamline Agama's workflow has not been replied to in over a year: https://github.com/openSUSE/agama/issues/601
Meanwhile this Project now does have offerings like Aeon (using it's own installer) which offer a more focused, single Desktop, single purpose approach which I think is a far better approach for people coming from the Windows or Mac World.
For what it's worth, I suspect we would have done this sooner if we had live installers like both Fedora and Ubuntu have. Both have independently shown that there's much more success by simplifying the installation experience with curated experiences rather than trying to teach people what components to select to get a good one. YaST is a very complex interface for installation, and as the necessary skills for administering a computer has reduced over time (which is not necessarily a bad thing!), YaST appears more and more like a barrier of entry than the guiding process it was intended to be.
I think that's a better way of addressing the problem rather than ruining what makes Tumbleweed awesome.
I think the installation and onboarding experience for Tumbleweed (and Leap too, for that matter) is pretty bad, actually. There's not much to "ruin" there. It's not Arch Linux, but it's definitely not easy for someone to figure out. Aeon's installation process is a massive step in the right direction. -- 真実はいつも一つ！/ Always, there's only one truth!
On Fri, 26 Jul 2024 13:54:36 +0200 Richard Brown <rbrown@suse.de> wrote:
On 2024-07-26 11:00, josef Reidinger wrote:
For example I mention on my talk on OSC that it would be nice to have for newbies default desktop selected in TW and Leap, to avoid unnecessary confusion for people coming from windows or mac world. So who should I contact for such decision?
Firstly, I'd like to say that I trust Dominique's Early Adopters team to steward Tumbleweed better than any other alternative.
I do not say that the team do bad work neither that someone else will do better job. I am just saying that if Tumbleweed is driven by SUSE, then I do not see it much as community distro from my POV.
I think deciding a default desktop for Tumbleweed or Leap is highly problematic:
- Both are general purpose distributions that could be Desktops, or Servers, or anything else - Both offer multiple desktops with vibrant volunteer communities actively supporting them
I wholly agree that those above points can make Tumbleweed or Leap more intimidating to new users. But I think elevating a single Desktop role to a default at the expense of the rest of the community (contributors & users) who use those distributions for other things, actually hurts more than it helps.
Well, question is what is expense? I just say that if there is agreement on one option, it can be default and user can change it with single click. Current state is that everyone needs that click even if they do not care much about what DE it will use or don't know it yet.
I think it's better for Tumbleweed and Leap to lead into the flexibility and excessive choice they offer. I also think this is better aligned with the realities of the Installers available for those distributions also. YaST historically has been very limited in it's ability to hide/remove options from users, which is precisely something that _needs_ to be done if the goal is to "avoid unnecessary confusion for people coming from windows or mac world"
Well, I do not want to hide/remove anything. I just would like to have simple next->next->next workflow with reasonable defaults and user will modify what they are interested in.
Agama currently seems to make that even worse, with it being necessary for someone to pick from a collection of different "Products/Distributions" first.
Well, it is not necessary. If you create live ISO with single product, then user do not need to select it. It is just ability to provide "something" that allows users to download opensuse iso and decide which product they want to install.
My request to make it possible to streamline Agama's workflow has not been replied to in over a year: https://github.com/openSUSE/agama/issues/601
Well, main goal of agama and we do not hide it, is to provide SLE16 installer. And any feature that is missing in installer cause complains, so we are currently more focused on adding stuff that customers wants than hiding features that agama can do. And if you see the latest agama on conference, you can see that it basically just say what user need to provide to make installation happen and rest is there if user want to change things, as we still want to offer as much freedom of choices as possible.
Meanwhile this Project now does have offerings like Aeon (using it's own installer) which offer a more focused, single Desktop, single purpose approach which I think is a far better approach for people coming from the Windows or Mac World.
Well, problem with this approach is that it just brings the user decision one level up. I often face it on opensuse booths on conferences that people want to try openSUSE and we try to explain difference between TW and Leap..and then there is also MicroOS and Leap Micro...and then Aeon and Kalpa and I do not want to imagine if lxqt, xfce4 or sway wants also their desktop.... But I have to admit that bigger Fedora also did this way with Silverblue, Kinoite, Sway Atomic or Budgie atomic, but even to some fedora people I talk to do not know about all of them. I am just having feeling that in fedora all those spins and labs isos is more like second or third class citizens beside 5 main editions. BTW this amount of opensuse distros result in idea of Agama installer that can install multiple distributions.
I think that's a better way of addressing the problem rather than ruining what makes Tumbleweed awesome.
I've been using SELinux in enforcing for ~12 months with mostly-favorable results. During that time, I've only encountered one real showstopper. I think this change is positive, although I hope apparmor will continue to be supported by the community as well. openSUSE's been wonderful enough to allow me to choose SELinux when it wasn't the primary choice, and I hope it'll continue to be wonderful to those who choose the path less traveled.
participants (15)
-
Andrei Borzenkov -
Cathy Hu -
Christian Boltz -
Dominique Leuenberger -
Georg Pfuetzenreuter -
Jiri Slaby -
Johannes Segitz -
josef Reidinger -
Joshua Smith -
Marcus Rückert -
Neal Gompa -
Richard Brown -
Richard Rahl -
Simon Lees -
Stefan Seyfried