See https://jira.suse.com/browse/SLE-15840 and https://jira.suse.com/browse/SLE-16698

PR: https://github.com/yast/yast-installation/pull/906

Trello: https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac

We need to cover:

• Defaults are as expected
• Changing options lead to the expected result in the installed system
• Autoyast cloning add all relevant sections in the profile

Autoyast doesn't have new specific functionality and should work with something like:

<sysconfig config:type="list" >
  <sysconfig_entry>
    <sysconfig_key>POLKIT_DEFAULT_PRIVS</sysconfig_key>
    <sysconfig_path>/etc/sysconfig/security</sysconfig_path>
    <sysconfig_value>restrictive</sysconfig_value>
  </sysconfig_entry>
</sysconfig>

Plus pattern installation. So we should focus on cloning of the profile as sysconfig section is not new.

Trello card content:
Discussion at https://jira.suse.com/browse/PM-2244
But the MicroOS request is here https://jira.suse.com/browse/SMO-20
And SLE 15 SP3 is at https://jira.suse.com/browse/SLE-17307
And Dev task: https://jira.suse.com/browse/SLE-17427

Review¶

TL;DR¶

Security-Enhanced Linux (aka SELinux) can be now proposed as a major Linux Security Module during the (auto)installation, offering a client for changing the suggested mode or disabling it (which means to still use AppArmor, the default major LSM in SUSE).

Among a bunch of changes, a new Y2Security::Selinux backend class, responsible to set needed boot kernel params for each mode and write the configuration, and new proposal and finish security clients have been added to achieve such feature implemented in both code streams, SP2 and master/SP3 (although in SP2 the proposal actually lives in yast-firewall)

All this goes with an increase in test coverage of touched repos :tada:. E.g, +2.0% in yast-installation and +4.4% in yast-security.

Fun fact: Did you know that SELinux was originally developed by NSA? :mag_right: :bug: :wink:

I didn't. Well, to be honest, I (David) did know NOTHING about SELinux/LSM before senselessly putting my face in this card.

The LONG story¶

The real LONG story could be a bit boring and starts in the referenced Jira entries in the card, where proposing SELinux enforcing mode for both, SUSE Micro OS and SLES SP3, was requested. But, in order to keep it not so long, let's just use this section to recap some relevant (or painful) points found during the implementation.

• The feature requires a pattern because, if I didn't get something wrong, is the way they are serving the needed packages to have SELinux working in each SUSE flavor, including the SELinux policy package. In fact, I asked that to Jiri since I saw he added a microos-selinux pattern in the SMO skelcd. And the answer was

However, if he enables it during installation, please, make sure that the pattern (or packages listed in its Requires) are installed

But, at this moment, SELinux patterns are only available for openSUSE Tumbleweed and SUSE MicroOS despite there is a Jira entry for SLES-15-SP3 too. Thus, we agreed to go ahead proposing it disabled instead of enforcing.

• Yast::PackagesProposal.(Set|Add)Resolvables has been fixed for not crashing when trying to add a not available pattern (https://github.com/yast/yast-packager/pull/548)
• AutoYaST has been fixed to be able to select proposed patterns even when not running in confirm mode (https://github.com/yast/yast-autoinstallation/pull/734)
• Although initially it was rejected, we finally end up moving the .autorelabel file from / to /etc/selinux when the root file-system will be mounted as read-only (https://github.com/yast/yast-security/pull/94)
• The proposal lives in the yast-firewall module for SP2 code stream to keep changes minimal
• The kernel boot params precedence is a sort of black magic (at least for David)

If you still hunger for knowledge, please feel free to follow the below links (and the links you will find along the way) to keep reading. Enjoy them! :wink:

• SLE-15-SP2 && SMO status (Feb 16th, 2021): https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-602bbce7c383b0825e738332
• SLE-15-SP3/master status (Feb 19th, 2021): https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-602f9165205c6107da6d12f3
• Moving .autorelabel file status (Feb 23th, 2021): https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-603523dc4e392e0bcffea310
• An issue found in yast2-packager: https://github.com/yast/yast-packager/pull/548
• An issue with AutoYaST (Feb 18th, 2021): fixed at https://github.com/yast/yast-autoinstallation/pull/734, for details see https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-602e9bc790690c206207509e and https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-6038d059028b04631bc092b0
• TW and Leap also wants to propose SELinux as major security module, but in permissive mode. See Lubos's comment at https://github.com/yast/yast-installation/pull/906#issuecomment-784238549
• Skelcds status: https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-6038d5cb48d0682cdaa8d39b

---

Main Points¶

• Implementation needed at SLE 15 SP2, then copied to SLE 15 SP3
• In installer, visible only via a control file entry for SLE 15 SP2
• Normal appearance for SLE 15 SP3 (for now)
• PLEASE, DO NOT IMPLEMENT ACCORDING TO THE DESCRIPTION IN THAT FEATURE, IT'S TRAP AND IT'S CRAP!

Appearance and Behavior in Installer¶

• Let's have this in "Security Settings" Summary, also configured via that option details
• Make this all available (and visible) ONLY if the control file says so (new control file entry for SP2)
• Set the default state via control file
• For MicroOS, SELinux should be enabled by default
• For SLE 15 SP3? We need to ask PM about it

Appearance and Behavior in Bootloader (running system)¶

• Just show it as additional Kernel parameters, i.e. NOOP

Appearance in Security Module (running system)¶

Although Thorsten says "we don't need... now", we actually need it for the running system as we are going to make it available for TW and SLE 15 SP3 too.

• Show the option only if selinux-policy-targeted (to be checked) package is available or installed
• Install the package if needed
• Hint for UI: Either use two items - Enable SELinux checkboxframe + Switch between Enforcing / Permissive; or Switch between Disabled, Enforcing and Permissive

Technical Details¶

• Add new "SELinux Policy" into the listing of Security module installation details
• With options: Disabled, Permissive (logging only), Enforcing (production systems) -- labels to be discussed with UX
• The default role should be set by control file / role (default is Enforcing)
• Adjust Kernel cmdline
  • Enforcing: "security=selinux selinux=1 enforcing=1"
  • Permissive: "security=selinux selinux=1", remove "enforcing=..."
  • Disabled: remove any mention "security=selinux" or "selinux=..." or "enforcing=..."
• Write settings to /etc/selinux/config at the end of installation
• Ignore the request to move /.autorelabel file, find out who/what creates the file and ask the maintainer to create it in another place if needed

Defaults¶

• For now MicroOS (based on 15 SP2): feature visible, enabled, enforcing
• For SLE 15 SP3: feature visible, disabled, enforcing
• For SLE 15 SP2: feature invisible

AutoYaST¶

• New AutoYaST Profile entry (selinux something) for Security module

AppArmor¶

• We currently do not support AppArmor, but we might think about at least one thing: How to make sure that these two ways of securing Linux do not fight each other. Or can they work together? Does that even make sense at all? If not, can and should we actively do something about it? To be researched