From Fedora Project Wiki
(Minor edits and rewording)
No edit summary
Line 5: Line 5:
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->
<!-- The actual name of your proposed change page should look something like: Changes/Your_Change_Proposal_Name.  This keeps all change proposals in the same namespace -->


Disable CONFIG_SECURITY_SELINUX_DISABLE<!-- The name of your change proposal --> =
Remove support for SELinux runtime disable<!-- The name of your change proposal --> =


== Summary ==
== Summary ==
Line 15: Line 15:
Remove support for SELinux runtime disable so that the LSM hooks can be hardened via read-only-after-initialization protections.
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.
Migrate users to using ''selinux=0'' if they want to disable SELinux.


== Owner ==
== Owner ==
Line 65: Line 65:
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->
<!-- Expand on the summary, if appropriate.  A couple sentences suffices to explain the goal, but the more details you can provide the better. -->


CONFIG_SECURITY_SELINUX_DISABLE functionality was originally developed to make it easier for Linux distributions to support architectures where adding parameters to the kernel command line was difficult.
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 LSM hooks.
SELinux runtime disable is enabled via ''CONFIG_SECURITY_SELINUX_DISABLE'' kernel build option which 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 LSM hooks as read only provides some very nice security benefits, but it does mean that we can no longer disable SELinux at runtime.
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).
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 selinuxfs unmounted,
System with '''SELINUX=disabled''' in '''/etc/selinux/config''' will come up with selinuxfs unmounted,
userspace will think SELinux is disabled, but internally SELinux will be enabled with no policy so that there will be no SELinux checks applied.
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.
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"
Current kernel reports the following message during runtime disable: ''SELinux:  Runtime disable is deprecated, use selinux=0 on the kernel cmdline''


Additional info:
Additional info:
Line 117: Line 118:
-->
-->


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 CONFIG_SECURITY_SELINUX_DISABLE enabled they have a bigger chance to turn off (parts of) SELinux permission checking.
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 ==
== Scope ==
Line 123: Line 124:
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the feature owners have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->


Make sure kernel is built without CONFIG_SECURITY_SELINUX_DISABLE
* Make sure kernel is built without CONFIG_SECURITY_SELINUX_DISABLE
 
* Make sure relevant documentation is updated in a way that ''selinux=0'' on kernel command line is preferred way to disable SELinux.
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
* Other developers: N/A (not a System Wide Change) <!-- REQUIRED FOR SYSTEM WIDE CHANGES -->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do other developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->

Revision as of 09:37, 26 August 2020


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


Current status

  • Targeted release: Fedora 34
  • Last updated: 2020-08-26
  • FESCo issue: <will be assigned by the Wrangler>
  • Tracker bug: <will be assigned by the Wrangler>
  • Release notes tracker: <will be assigned by the Wrangler>

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. SELinux runtime disable is enabled via CONFIG_SECURITY_SELINUX_DISABLE kernel build option which 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 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:

Feedback

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 kernel is built without CONFIG_SECURITY_SELINUX_DISABLE
  • Make sure relevant documentation is updated in a way that selinux=0 on kernel command line is preferred way to disable SELinux.
  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

Users should not be directly affected by this change.

How To Test

N/A (not a System Wide Change)

  1. Confirm that is disabled when selinux=0 is used on kernel command line
  2. Confirm that userspace consider SELinux disabled when SELINUX=disabled is used in /etc/selinux/config
  3. Confirm that system works as expected in both 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 instead of '-'. These users will be also able to load SELinux policy after boot.

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Documentation

N/A (not a System Wide Change)

Release Notes