Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Wed, Sep 16, 2020 at 04:07:11PM +0200, Ondrej Mosnacek wrote:
> On Thu, Sep 10, 2020 at 6:05 PM Robbie Harwood  wrote:
> >
> > Ondrej Mosnacek  writes:
> >
> > > James Cassell wrote:
> > >> Ben Cotton wrote:
> > >>
> > >>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> > >>>
> > >>> == Summary ==
> > >>> Remove support for SELinux runtime disable so that the LSM hooks can
> > >>> be hardened via read-only-after-initialization protections.
> > >>>
> > >>> Migrate users to using ''selinux=0'' if they want to disable SELinux.
> > >>
> > >> I like the proposal. A few thoughts and questions, though:
> > >>
> > >> 1. I think systems with SELINUX=disabled without selinux=0 should
> > >> hard fail very loudly.
> > >
> > > That's an interesting opinion... It would be easier and more direct to
> > > do it that way, but we are worried that users would complain that
> > > their SELINUX=disabled setup is suddenly broken and they need to mess
> > > with the bootloader to get a working system again. (I don't know that
> > > much about real-time systems, so feel free to correct/enlighten me
> > > here.) That's why we try to make sure that things keep working
> > > more-or-less the same as before.
> >
> > Please correct me if I'm wrong, but *aren't* those systems broken?  That
> > is, if an admin sets selinux=disabled on a system after this change has
> > (hypothetically) gone through, won't they have a system in which selinux
> > isn't disabled?  Or is there going to be migration logic in perpetuity?
> 
> I wouldn't say they are broken. They rely on a feature that has been a
> supported and kind-of standard way to disable SELinux until now. After
> this proposal would be implemented, they would still get a state that
> is very close to SELinux being disabled, so I don't think we need to
> go as far as e.g. refusing to boot with such configuration.

And btw, even current /etc/selinux/config describes the future situation:

# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.

^^ this is exactly what will happen when this change is accepted. SELinux will
be enabled internally in kernel but no policy will be loaded and as it was
already explained, for user this situation should be almost the same as  SELinux
disabled. The difference will be only in kernel internal level.


> Of course, it would be great if we could somehow alert the sysadmin
> that they should change their configuration if they have
> SELINUX=disabled in /etc/selinux/config but no selinux=0 on kernel
> cmdline, but I'm not sure if there is an established way to do that in
> Fedora (other than documenting such things in Release notes). On RHEL,
> this is possible via LEAPP or Red Hat Insights, but  what can you do
> on Fedora? Printing warnings/errors anywhere is not reliable, because
> the system (or even a cluster of systems) may be managed only remotely
> with the admin logging in only when something breaks. Or is there some
> established way of telling the admin: "Hey, your system may not seem
> broken, but there is this configuration issue that needs your
> attention."?
> 

Maybe we could add a oneshot systemd unit which would warn users when
/etc/selinux/config contains SELINUX=disabled but it's not disabled in kernel.


Petr

signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 6:05 PM Robbie Harwood  wrote:
>
> Ondrej Mosnacek  writes:
>
> > James Cassell wrote:
> >> Ben Cotton wrote:
> >>
> >>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >>>
> >>> == Summary ==
> >>> Remove support for SELinux runtime disable so that the LSM hooks can
> >>> be hardened via read-only-after-initialization protections.
> >>>
> >>> Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >>
> >> I like the proposal. A few thoughts and questions, though:
> >>
> >> 1. I think systems with SELINUX=disabled without selinux=0 should
> >> hard fail very loudly.
> >
> > That's an interesting opinion... It would be easier and more direct to
> > do it that way, but we are worried that users would complain that
> > their SELINUX=disabled setup is suddenly broken and they need to mess
> > with the bootloader to get a working system again. (I don't know that
> > much about real-time systems, so feel free to correct/enlighten me
> > here.) That's why we try to make sure that things keep working
> > more-or-less the same as before.
>
> Please correct me if I'm wrong, but *aren't* those systems broken?  That
> is, if an admin sets selinux=disabled on a system after this change has
> (hypothetically) gone through, won't they have a system in which selinux
> isn't disabled?  Or is there going to be migration logic in perpetuity?

I wouldn't say they are broken. They rely on a feature that has been a
supported and kind-of standard way to disable SELinux until now. After
this proposal would be implemented, they would still get a state that
is very close to SELinux being disabled, so I don't think we need to
go as far as e.g. refusing to boot with such configuration.

Of course, it would be great if we could somehow alert the sysadmin
that they should change their configuration if they have
SELINUX=disabled in /etc/selinux/config but no selinux=0 on kernel
cmdline, but I'm not sure if there is an established way to do that in
Fedora (other than documenting such things in Release notes). On RHEL,
this is possible via LEAPP or Red Hat Insights, but  what can you do
on Fedora? Printing warnings/errors anywhere is not reliable, because
the system (or even a cluster of systems) may be managed only remotely
with the admin logging in only when something breaks. Or is there some
established way of telling the admin: "Hey, your system may not seem
broken, but there is this configuration issue that needs your
attention."?

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Robbie Harwood]

Ondrej Mosnacek  writes:

> James Cassell wrote:
>> Ben Cotton wrote:
>>
>>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>>>
>>> == Summary ==
>>> Remove support for SELinux runtime disable so that the LSM hooks can
>>> be hardened via read-only-after-initialization protections.
>>>
>>> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>>
>> I like the proposal. A few thoughts and questions, though:
>>
>> 1. I think systems with SELINUX=disabled without selinux=0 should
>> hard fail very loudly.
>
> That's an interesting opinion... It would be easier and more direct to
> do it that way, but we are worried that users would complain that
> their SELINUX=disabled setup is suddenly broken and they need to mess
> with the bootloader to get a working system again. (I don't know that
> much about real-time systems, so feel free to correct/enlighten me
> here.) That's why we try to make sure that things keep working
> more-or-less the same as before.

Please correct me if I'm wrong, but *aren't* those systems broken?  That
is, if an admin sets selinux=disabled on a system after this change has
(hypothetically) gone through, won't they have a system in which selinux
isn't disabled?  Or is there going to be migration logic in perpetuity?

Thanks,
--Robbie


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 4:05 PM Michal Schorm  wrote:
> On Thu, Sep 10, 2020 at 3:58 PM Ondrej Mosnacek  wrote:
> > On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> > > Does this mean, the "setenforce 0" won't work anymore?
> > No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
> > "Permissive" mode) would not be affected and would work as before.
>
> That wasn't clear to me.
> Might be nice to add such a few words to the proposal.

Good point! I added a note about permissive vs. disabled to the summary:
https://fedoraproject.org/w/index.php?title=Changes%2FRemove_Support_For_SELinux_Runtime_Disable=revision=587713=587708

Thanks,

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Thu, Sep 10, 2020 at 03:46:38PM +0200, Michal Schorm wrote:
> Does this mean, the "setenforce 0" won't work anymore?

No, setenforce will not be affected by this change.

> I use it quite a lot to examine the denials and audit2allow to
> generate updated rules which fixes my issues.
> 
> I would see the inability of such workflow as a major drawback for
> *anyone* who doesn't just consume the default configuration.
> e.g. "My database datadir should reside elsewhere"; "my container
> should access pulseaudio socket"; "I've ran the default configuration
> with my data and it crashed" ...
> 

setenforce works only in SELinux enabled system and `setenforce 0` is to put
SELinux in permissive mode (not to disable SELinux), see "SELinux states and 
modes" at 
https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/

Also it will be possible to switch between enforcing and permissive
using SELINUX=enforcing resp SELINUX=permissive in /etc/selinux/config as it is
now.

Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Michal Schorm]

On Thu, Sep 10, 2020 at 3:58 PM Ondrej Mosnacek  wrote:
> On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> > Does this mean, the "setenforce 0" won't work anymore?
> No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
> "Permissive" mode) would not be affected and would work as before.

That wasn't clear to me.
Might be nice to add such a few words to the proposal.

Thanks for clarification.

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 3:48 PM Michal Schorm  wrote:
> Does this mean, the "setenforce 0" won't work anymore?

No, no, don't worry, "setenforce 0" (i.e. switching SELinux to
"Permissive" mode) would not be affected and would work as before.

The proposal is only about fully disabling SELinux. Gentoo happens to
have a nice article about the different SELinux modes/states:
https://wiki.gentoo.org/wiki/SELinux/Tutorials/Permissive_versus_enforcing

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 2:28 PM Richard Hughes  wrote:
> On Thu, 10 Sep 2020 at 12:38, Neal Gompa  wrote:
> > Because Red Hat customers put the SELinux policy developers into
> > no-win situations: they complain about AVC denials that don't actually
> > significantly break anything in *their* app
>
> My response to that would be to ship a "AVC ignore-list" config file
> in userspace alongside the customer application -- rather than just
> pretending that SELinux didn't do anything at all for all apps.

That has another disadvantage, though: all the false-positive denials
would then fill up the audit log (the frequency can be quite high),
i.e. either taking up extra space on disk or pushing out other,
potentially valuable, audit records. Not to mention the CPU cycles
wasted by the audit stack to process the records. Dontaudit by default
+ semodule -DB for debugging is IMHO the only reasonable compromise.

Anyway, this is getting off-topic w,r,t. the proposal. Please start a
new thread if you want to continue discussing dontaudit rules.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Michal Schorm]

Does this mean, the "setenforce 0" won't work anymore?

I use it quite a lot to examine the denials and audit2allow to
generate updated rules which fixes my issues.

I would see the inability of such workflow as a major drawback for
*anyone* who doesn't just consume the default configuration.
e.g. "My database datadir should reside elsewhere"; "my container
should access pulseaudio socket"; "I've ran the default configuration
with my data and it crashed" ...

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Petr Lautrbach]

On Wed, Sep 09, 2020 at 10:24:00AM +0200, Vít Ondruch wrote:
> Generally, I would appreciate if the proposal was more readable to
> casual Fedora user/developer. I don't think there is clearly described
> the current state and what is going to be changed. Also, there is a lot
> of unclear terminology, e.g. I don't have idea what are "LSM hooks".
> "Migrate users to using ''selinux=0''" probably refers to kernel command
> line, but why it is not mentioned in the summary.
> 

I've updated the page to:

- provide links which should descride LSM hooks and 
read-only-after-initialization protection.
- be more decriptive about the cuurent state and the change


https://fedoraproject.org/w/index.php?title=Changes%2FRemove_Support_For_SELinux_Runtime_Disable=revision=587708=587533

Thanks!

Petr

>
> 
> Dne 08. 09. 20 v 17:28 Ben Cotton napsal(a):
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
> > == Owner ==
> > * Name: [[User:plautrba| Petr Lautrbach]]
> > * Email: plaut...@redhat.com
> > * Name: [[User:omos| Ondrej Mosnacek]]
> > * Email: omosn...@redhat.com
> >
> >
> > == Detailed Description ==
> > Support for SELinux runtime disable via ''/etc/selinux/config'' was
> > originally developed to make it easier for Linux distributions to
> > support architectures where adding parameters to the kernel command
> > line was difficult.
> > Unfortunately, supporting runtime disable meant we had to make some
> > security trade-offs when it comes to the kernel LSM hooks.
> >
> > Marking the kernel LSM hooks as read only provides some very nice
> > security benefits, but it does mean that we can no longer disable
> > SELinux at runtime.
> > Toggling between enforcing and permissive mode while booted will
> > remain unaffected and it will still be possible to disable SELinux by
> > adding ''selinux=0'' to the kernel command line via the boot loader
> > (GRUB).
> >
> > System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> > up with ''/sys/fs/selinuxfs'' unmounted,
> > userspace will detect SELinux as disabled. Internally SELinux will be
> > enabled but not initialized so that there will be no SELinux checks
> > applied.
> >
> > NOTE: Runtime disable is considered deprecated by upstream, and using
> > it will become increasingly painful (e.g. sleeping/blocking) through
> > future kernel releases until eventually it is removed completely.
> > Current kernel reports the following message during runtime disable:
> > ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> > cmdline''
> >
> > Additional info:
> >
> > * https://lwn.net/Articles/666550
> > * 
> > https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> > * 
> > https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
> >
> > == Benefit to Fedora ==
> > Marking the LSM hooks as read-only provides extra security hardening
> > against certain attacks, e.g. in case an attacker gains ability to
> > write to random kernel memory locations, with support for disable
> > SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> > bigger chance to turn off (parts of) SELinux permission checking.
> >
> > == Scope ==
> > * Proposal owners:
> > ** Make sure the kernel is built with
> > ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> > ** Make sure the relevant documentation is updated in a way that
> > ''selinux=0'' on kernel command line is the preferred way to disable
> > SELinux.
> > *** 
> > https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> > *** ''selinux(8)'' man page
> > ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> > uses the kernel command line instead of ''/etc/selinux/config'' to
> > disable SELinux.
> > ** Optional: 
> > [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> > ''selinux'' Ansible module] should warn that SELinux needs to be
> > disabled using ''selinux=0''.
> > ** Optional: [https://github.com/linux-system-roles/selinux
> > linux-system-roles.selinux] should disable SELinux using
> > ''selinux=0''.
> >
> > * Other developers: N/A
> > * Release engineering: https://pagure.io/releng/issue/9742
> > * Policies and guidelines: N/A
> > * Trademark approval: N/A (not needed for this Change)
> >
> >
> > == Upgrade/compatibility impact ==
> > Users should not be directly affected by this change.
> >
> > == How To Test ==
> > # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
> > disabled, e.g. from
> > https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
> > # Confirm that SELinux is disabled when ''selinux=0'' is used on
> > kernel command 

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Mauricio Tavares]

On Thu, Sep 10, 2020 at 7:38 AM Neal Gompa  wrote:
>
> On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
> >
> > On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > > Speaking from personal experience, I've wasted days over the last
> > > > decade trying to debug a locally installed system service that was not
> > > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > > -- and turning off selinux at runtime magically fixed the problem.
> > >
> > > Some selinux rules are marked to not generate AVCs...
> >
> > Why!? There's sometimes no log output anywhere obvious that a syscall
> > or something was blocked. It's the reason I turn off selinux on my
> > work development machine, and I've often wasted *hours* of my life on
> > code "doing something impossible" over the last decade until a neuron
> > at the back of my brain remembers "you've not yet turned off selinux"
> > and then when I "sudo setenforce 0" it works, and I can't actually
> > file a bug as there's no indication of what selinux actually blocked
> > or why.
> >
>
> Because Red Hat customers put the SELinux policy developers into
> no-win situations: they complain about AVC denials that don't actually
> significantly break anything in *their* app and often just disable
> SELinux in those scenarios. Red Hat wants customers to use it and not
> freak out all the time, so these kinds of things get added because it
> is very hard to come up with the right rules for all cases and there's
> not enough time to work on that.
>
> (I know for a fact that more than a few dontaudit rules were the
> result of those kinds of conversations, because I witnessed them)
>
  Stupid question: if the audit just reports selinux barked but it
did not block, why completely block the reporting? Because customers
were freaking out about the entries in the audit log itself?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Richard Hughes]

On Thu, 10 Sep 2020 at 12:38, Neal Gompa  wrote:
> Because Red Hat customers put the SELinux policy developers into
> no-win situations: they complain about AVC denials that don't actually
> significantly break anything in *their* app

My response to that would be to ship a "AVC ignore-list" config file
in userspace alongside the customer application -- rather than just
pretending that SELinux didn't do anything at all for all apps.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Neal Gompa]

On Thu, Sep 10, 2020 at 7:33 AM Richard Hughes  wrote:
>
> On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > > Speaking from personal experience, I've wasted days over the last
> > > decade trying to debug a locally installed system service that was not
> > > working where there were no messages in any of the logs (e.g. no AVCs)
> > > -- and turning off selinux at runtime magically fixed the problem.
> >
> > Some selinux rules are marked to not generate AVCs...
>
> Why!? There's sometimes no log output anywhere obvious that a syscall
> or something was blocked. It's the reason I turn off selinux on my
> work development machine, and I've often wasted *hours* of my life on
> code "doing something impossible" over the last decade until a neuron
> at the back of my brain remembers "you've not yet turned off selinux"
> and then when I "sudo setenforce 0" it works, and I can't actually
> file a bug as there's no indication of what selinux actually blocked
> or why.
>

Because Red Hat customers put the SELinux policy developers into
no-win situations: they complain about AVC denials that don't actually
significantly break anything in *their* app and often just disable
SELinux in those scenarios. Red Hat wants customers to use it and not
freak out all the time, so these kinds of things get added because it
is very hard to come up with the right rules for all cases and there's
not enough time to work on that.

(I know for a fact that more than a few dontaudit rules were the
result of those kinds of conversations, because I witnessed them)




--
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Richard Hughes]

On Thu, 10 Sep 2020 at 10:17, Tom Hughes  wrote:
> > Speaking from personal experience, I've wasted days over the last
> > decade trying to debug a locally installed system service that was not
> > working where there were no messages in any of the logs (e.g. no AVCs)
> > -- and turning off selinux at runtime magically fixed the problem.
>
> Some selinux rules are marked to not generate AVCs...

Why!? There's sometimes no log output anywhere obvious that a syscall
or something was blocked. It's the reason I turn off selinux on my
work development machine, and I've often wasted *hours* of my life on
code "doing something impossible" over the last decade until a neuron
at the back of my brain remembers "you've not yet turned off selinux"
and then when I "sudo setenforce 0" it works, and I can't actually
file a bug as there's no indication of what selinux actually blocked
or why.

Richard
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 11:18 AM Tom Hughes via devel
 wrote:
> On 10/09/2020 09:44, Richard Hughes wrote:
> > On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:
> >> NOTE: Runtime disable is considered deprecated by upstream, and using
> >> it will become increasingly painful (e.g. sleeping/blocking) through
> >> future kernel releases until eventually it is removed completely.
> >
> > Speaking from personal experience, I've wasted days over the last
> > decade trying to debug a locally installed system service that was not
> > working where there were no messages in any of the logs (e.g. no AVCs)
> > -- and turning off selinux at runtime magically fixed the problem.
>
> Some selinux rules are marked to not generate AVCs...

Yes, these are called "dontaudit" rules. They are used for when the
impact of a failed access check doesn't prevent the application from
functioning and we don't want to allow that access vector (e.g. when
the application just checks to see if it can do some privileged
operation and if not, it continues with some fallback). Unfortunately,
it can happen sometimes that such a rule hides some denial that
actually does break something.

They can be temporarily disabled by running `semodule -DB` and then
re-enabled again with `semodule -B`.

>
> > Whilst I'm of course in favour of fixing the lockdown issue, would it
> > also be fair to say that any selinux regression not triggering an AVC
> > (which is fixed using selinux=0) would block this kind of proposal?
>
> Did "setenforce 0" also fix it?

If the issue is in (or rather hidden by) the dontaudit rules, then
"setenforce 0" should indeed make it work as well.

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

On Thu, Sep 10, 2020 at 11:18 AM Florian Weimer  wrote:
> * Ben Cotton:
>
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
> > == Owner ==
> > * Name: [[User:plautrba| Petr Lautrbach]]
> > * Email: plaut...@redhat.com
> > * Name: [[User:omos| Ondrej Mosnacek]]
> > * Email: omosn...@redhat.com
> >
> >
> > == Detailed Description ==
> > Support for SELinux runtime disable via ''/etc/selinux/config'' was
> > originally developed to make it easier for Linux distributions to
> > support architectures where adding parameters to the kernel command
> > line was difficult.
> > Unfortunately, supporting runtime disable meant we had to make some
> > security trade-offs when it comes to the kernel LSM hooks.
> >
> > Marking the kernel LSM hooks as read only provides some very nice
> > security benefits, but it does mean that we can no longer disable
> > SELinux at runtime.
>
> Could the static_call framework be used instead for this?
>
>   

AFAIK the static_call framework is about mitigating the performance
impact of indirect calls (basically function pointers), while this
proposal is about allowing the security hook function pointers to be
marked read-only after all built-in kernel modules have been
initialized (IOW after the hook lists have been set up based on the
kernel cmdline), which means an attacker wouldn't be able to
neutralize the hooks by overwriting the function pointers.

So unless I misunderstand something, these are two orthogonal
solutions to different problems - you would still have the possibility
to overwrite the hook calls after (only) converting to static_call and
also this proposal doesn't solve the indirect-call performance
problem.

BTW, there has been an RFC patch for switching LSM hooks to use
static_call, but the result is quite ugly-looking code, unfortunately:
https://lore.kernel.org/linux-security-module/20200820164753.3256899-1-jackm...@chromium.org/

-- 
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Tom Hughes via devel]

On 10/09/2020 09:44, Richard Hughes wrote:

On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:

NOTE: Runtime disable is considered deprecated by upstream, and using
it will become increasingly painful (e.g. sleeping/blocking) through
future kernel releases until eventually it is removed completely.


Speaking from personal experience, I've wasted days over the last
decade trying to debug a locally installed system service that was not
working where there were no messages in any of the logs (e.g. no AVCs)
-- and turning off selinux at runtime magically fixed the problem.


Some selinux rules are marked to not generate AVCs...


Whilst I'm of course in favour of fixing the lockdown issue, would it
also be fair to say that any selinux regression not triggering an AVC
(which is fixed using selinux=0) would block this kind of proposal?


Did "setenforce 0" also fix it?

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Florian Weimer]

* Ben Cotton:

> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.

Could the static_call framework be used instead for this?

  

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Richard Hughes]

On Tue, 8 Sep 2020 at 16:29, Ben Cotton  wrote:
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.

Speaking from personal experience, I've wasted days over the last
decade trying to debug a locally installed system service that was not
working where there were no messages in any of the logs (e.g. no AVCs)
-- and turning off selinux at runtime magically fixed the problem.

Whilst I'm of course in favour of fixing the lockdown issue, would it
also be fair to say that any selinux regression not triggering an AVC
(which is fixed using selinux=0) would block this kind of proposal?

Richard.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Ondrej Mosnacek]

Hi James,

On Tue, Sep 8, 2020 at 8:43 PM James Cassell
 wrote:
> On Tue, Sep 8, 2020, at 11:28 AM, Ben Cotton wrote:
> > https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> >
> > == Summary ==
> > Remove support for SELinux runtime disable so that the LSM hooks can
> > be hardened via read-only-after-initialization protections.
> >
> > Migrate users to using ''selinux=0'' if they want to disable SELinux.
> >
>
> I like the proposal. A few thoughts and questions, though:
>
> 1. I think systems with SELINUX=disabled without selinux=0 should hard fail 
> very loudly.

That's an interesting opinion... It would be easier and more direct to
do it that way, but we are worried that users would complain that
their SELINUX=disabled setup is suddenly broken and they need to mess
with the bootloader to get a working system again. (I don't know that
much about real-time systems, so feel free to correct/enlighten me
here.) That's why we try to make sure that things keep working
more-or-less the same as before.

> I've found certain real-time use cases require SELinux to be disabled to meet 
> the real time guarantees. (Permissive doesn't help because it's a timing 
> issue, not permission issue.)

I'd argue that when going real-time, you need to use a modified kernel
anyway and in that case it should be easier to just disable
CONFIG_SECURITY_SELINUX entirely in it. But maybe there can be a
situation where you get some 3rd party real-time kernel which has
SELinux enabled but it's the only thing breaking the latency for your
use case. In that case you'd really need to get SELinux disabled
properly.

Anyway, SELinux enabled with no policy loaded should be closer to
SElinux disabled than to SELinux permissive. In that scenario the
hooks are active, but they mostly do almost nothing. There should be
very little effect on time spent in syscalls compared to SELinux fully
disabled.

>
> 2. Does this affect resetting the root password with init=/bin/bash and using 
> `/sbin/load_policy -i` to avoid a relabel?

Booting with init=/bin/bash either doesn't currently work on Fedora,
or I'm doing it wrong... Anyway, on a system without selinux=0 and
with SELINUX=enforcing or =permissive in /etc/selinux/config, it will
always be possible to load a policy if it hasn't been loaded yet. Not
sure about SELINUX=disabled, but I think it should behave the same as
before. (And with selinux=0 it obviously isn't possible neither
before, nor after this change.)

>
> 3. Generally, forcing things to be cmdline options would benefit from a 
> generic way to configure and manage them, such as using drop-in snippets. 
> Ideally this would work the same way across BIOS and UEFI systems. It's 
> difficult to programmatically manipulate GRUB_CMDLINE_LINUX, which is the 
> current standard configuration method.

I agree that kernel cmdline management is a pain on Fedora/Linux, but
improving that is beyond what we (the proposal owners and our team)
can do :( This is on the shoulders of bootloader maintainers, although
I understand that refactoring GRUB/zipl to improve this would likely
be a pretty heroic endeavor...

I plan to at least add some convenience scripts to the selinux-policy
package that would do the "add/remove selinux=0 to/from
GRUB_CMDLINE_LINUX and run grub2-mkconfig" dance automatically so that
there is still some convenient way of disabling SELinux for those who
need it (at least on non-s390x systems).

>
> Thanks for putting the security-enhancing proposal forward!

And thank you for the valuable feedback!

--
Ondrej Mosnacek
Software Engineer, Platform Security - SELinux kernel
Red Hat, Inc.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Vít Ondruch]

Generally, I would appreciate if the proposal was more readable to
casual Fedora user/developer. I don't think there is clearly described
the current state and what is going to be changed. Also, there is a lot
of unclear terminology, e.g. I don't have idea what are "LSM hooks".
"Migrate users to using ''selinux=0''" probably refers to kernel command
line, but why it is not mentioned in the summary.


Thanks


Vít


Dne 08. 09. 20 v 17:28 Ben Cotton napsal(a):
> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
>
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
>
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
>
> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
>
>
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
>
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.
> Toggling between enforcing and permissive mode while booted will
> remain unaffected and it will still be possible to disable SELinux by
> adding ''selinux=0'' to the kernel command line via the boot loader
> (GRUB).
>
> System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> up with ''/sys/fs/selinuxfs'' unmounted,
> userspace will detect SELinux as disabled. Internally SELinux will be
> enabled but not initialized so that there will be no SELinux checks
> applied.
>
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.
> Current kernel reports the following message during runtime disable:
> ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> cmdline''
>
> Additional info:
>
> * https://lwn.net/Articles/666550
> * 
> https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> * 
> https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
>
> == Benefit to Fedora ==
> Marking the LSM hooks as read-only provides extra security hardening
> against certain attacks, e.g. in case an attacker gains ability to
> write to random kernel memory locations, with support for disable
> SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> bigger chance to turn off (parts of) SELinux permission checking.
>
> == Scope ==
> * Proposal owners:
> ** Make sure the kernel is built with
> ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> ** Make sure the relevant documentation is updated in a way that
> ''selinux=0'' on kernel command line is the preferred way to disable
> SELinux.
> *** 
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> *** ''selinux(8)'' man page
> ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> uses the kernel command line instead of ''/etc/selinux/config'' to
> disable SELinux.
> ** Optional: 
> [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> ''selinux'' Ansible module] should warn that SELinux needs to be
> disabled using ''selinux=0''.
> ** Optional: [https://github.com/linux-system-roles/selinux
> linux-system-roles.selinux] should disable SELinux using
> ''selinux=0''.
>
> * Other developers: N/A
> * Release engineering: https://pagure.io/releng/issue/9742
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> Users should not be directly affected by this change.
>
> == How To Test ==
> # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
> disabled, e.g. from
> https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
> # Confirm that SELinux is disabled when ''selinux=0'' is used on
> kernel command line.
> # Confirm that userspace considers SELinux disabled when
> ''SELINUX=disabled'' is used in ''/etc/selinux/config''.
> # Confirm that userspace considers SELinux disabled when there is no
> ''/etc/selinux/config''.
> # Confirm that the system works as expected in all previous cases.
>
> == User Experience ==
> There's no visible change for users with SELinux enabled.
>
> Users with ''SELINUX=disabled'' in ''/etc/selinux/config'' and without
> ''selinux=0'' on kernel command line might notice that `ps Z` command
> uses ''kernel'' domain for processes, while with 

Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[James Cassell]

On Tue, Sep 8, 2020, at 11:28 AM, Ben Cotton wrote:
> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable
> 
> == Summary ==
> Remove support for SELinux runtime disable so that the LSM hooks can
> be hardened via read-only-after-initialization protections.
> 
> Migrate users to using ''selinux=0'' if they want to disable SELinux.
> 

I like the proposal. A few thoughts and questions, though:

1. I think systems with SELINUX=disabled without selinux=0 should hard fail 
very loudly. I've found certain real-time use cases require SELinux to be 
disabled to meet the real time guarantees. (Permissive doesn't help because 
it's a timing issue, not permission issue.)

2. Does this affect resetting the root password with init=/bin/bash and using 
`/sbin/load_policy -i` to avoid a relabel?

3. Generally, forcing things to be cmdline options would benefit from a generic 
way to configure and manage them, such as using drop-in snippets. Ideally this 
would work the same way across BIOS and UEFI systems. It's difficult to 
programmatically manipulate GRUB_CMDLINE_LINUX, which is the current standard 
configuration method.

Thanks for putting the security-enhancing proposal forward!

V/r,
James Cassell


> == Owner ==
> * Name: [[User:plautrba| Petr Lautrbach]]
> * Email: plaut...@redhat.com
> * Name: [[User:omos| Ondrej Mosnacek]]
> * Email: omosn...@redhat.com
> 
> 
> == Detailed Description ==
> Support for SELinux runtime disable via ''/etc/selinux/config'' was
> originally developed to make it easier for Linux distributions to
> support architectures where adding parameters to the kernel command
> line was difficult.
> Unfortunately, supporting runtime disable meant we had to make some
> security trade-offs when it comes to the kernel LSM hooks.
> 
> Marking the kernel LSM hooks as read only provides some very nice
> security benefits, but it does mean that we can no longer disable
> SELinux at runtime.
> Toggling between enforcing and permissive mode while booted will
> remain unaffected and it will still be possible to disable SELinux by
> adding ''selinux=0'' to the kernel command line via the boot loader
> (GRUB).
> 
> System with ''SELINUX=disabled'' in ''/etc/selinux/config'' will come
> up with ''/sys/fs/selinuxfs'' unmounted,
> userspace will detect SELinux as disabled. Internally SELinux will be
> enabled but not initialized so that there will be no SELinux checks
> applied.
> 
> NOTE: Runtime disable is considered deprecated by upstream, and using
> it will become increasingly painful (e.g. sleeping/blocking) through
> future kernel releases until eventually it is removed completely.
> Current kernel reports the following message during runtime disable:
> ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel
> cmdline''
> 
> Additional info:
> 
> * https://lwn.net/Articles/666550
> * 
> https://lore.kernel.org/selinux/159110207843.57260.5661475689740939480.stgit@chester/
> * 
> https://lore.kernel.org/selinux/157836784986.560897.13893922675143903084.stgit@chester/#t
> 
> == Benefit to Fedora ==
> Marking the LSM hooks as read-only provides extra security hardening
> against certain attacks, e.g. in case an attacker gains ability to
> write to random kernel memory locations, with support for disable
> SELinux runtime (''CONFIG_SECURITY_SELINUX_DISABLE=y'') they have a
> bigger chance to turn off (parts of) SELinux permission checking.
> 
> == Scope ==
> * Proposal owners:
> ** Make sure the kernel is built with
> ''CONFIG_SECURITY_SELINUX_DISABLE'' disabled.
> ** Make sure the relevant documentation is updated in a way that
> ''selinux=0'' on kernel command line is the preferred way to disable
> SELinux.
> *** 
> https://docs.fedoraproject.org/en-US/quick-docs/changing-selinux-states-and-modes/
> *** ''selinux(8)'' man page
> ** Make sure [https://github.com/rhinstaller/anaconda/ the installer]
> uses the kernel command line instead of ''/etc/selinux/config'' to
> disable SELinux.
> ** Optional: 
> [https://github.com/ansible/ansible/blob/devel/lib/ansible/module_utils/facts/system/selinux.py
> ''selinux'' Ansible module] should warn that SELinux needs to be
> disabled using ''selinux=0''.
> ** Optional: [https://github.com/linux-system-roles/selinux
> linux-system-roles.selinux] should disable SELinux using
> ''selinux=0''.
> 
> * Other developers: N/A
> * Release engineering: https://pagure.io/releng/issue/9742
> * Policies and guidelines: N/A
> * Trademark approval: N/A (not needed for this Change)
> 
> 
> == Upgrade/compatibility impact ==
> Users should not be directly affected by this change.
> 
> == How To Test ==
> # Install a kernel built with ''CONFIG_SECURITY_SELINUX_DISABLE''
> disabled, e.g. from
> https://copr.fedorainfracloud.org/coprs/omos/drop-selinux-disable/.
> # Confirm that SELinux is disabled when ''selinux=0'' is used on
> kernel command line.
> # Confirm that userspace considers SELinux disabled when
> ''SELINUX=disabled'' is used