action #89104

[SLE-16698][SLE-15840] QA: Security policy choosing for SLES+WE

Added by riafarov about 2 years ago. Updated almost 2 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


See and



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" >

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

Trello card content:
Discussion at
But the MicroOS request is here
And SLE 15 SP3 is at
And Dev task:



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.

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:

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)

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


  • 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


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


  • 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


#1 Updated by riafarov almost 2 years ago

  • Status changed from Blocked to New

#2 Updated by riafarov almost 2 years ago

  • Description updated (diff)

#3 Updated by riafarov almost 2 years ago

  • Description updated (diff)

#4 Updated by riafarov almost 2 years ago

  • Description updated (diff)
  • Status changed from New to Workable

#5 Updated by riafarov almost 2 years ago

  • Status changed from Workable to In Progress
  • Assignee set to riafarov

#6 Updated by riafarov almost 2 years ago

  • Status changed from In Progress to Resolved

Filed #90695 for the second round once bugs are fixed.

Also available in: Atom PDF