Add a security policy validation mechanism

[imobachgs]

This PR adds security policy validation to the installer (see https://www.open-scap.org/security-policies/choosing-policy/).

• https://jira.suse.com/browse/PM-3526
• https://trello.com/c/SqFGWTyB
• https://trello.com/c/wcwOKwjK
• https://trello.com/c/4rwfhcTt

Related PRs:

• https://github.com/yast/yast-storage-ng/pull/1308.
• https://github.com/yast/yast-autoinstallation/pull/845
• https://github.com/yast/yast-installation/pull/1059

• 131

• 132

• 133

• 134

• 135

• 136

• 138

• https://github.com/yast/skelcd-control-leanos/pull/96

How it works

See the screenshots below to get an idea of how it works. Once the user enables a security profile (at this point only DISA STIG), YaST:

• Add the required package (ssg-apply) and enable the service at the end of the installation.
• Runs a set of checks and displays the rules that are not passing.
  • If the problem can be fixed automatically, it displays a link to do it.
  • Otherwise, it might display a link to take the user to the right place of the installer to solve it.

Installation settings including a 'Security Policy' section


Storage proposal showing found problems with the current configuration


YaST warning about an issue in the expert partitioner


AutoYaST confirmation mode when some rule failed


Do not allow installing the system until all problems are solved


Enabling security policy validation

There are three different ways to enable policy checks:

• Clicking "enable" on the installation summary page.
• Passing the option YAST_SECURITY_POLICIES=stig at boot time.
• Using AutoYaST (see https://github.com/yast/yast-autoinstallation/pull/845 for further details).

What is missing?

Write the name of the enabled policies and disabled rules to the file system, so ssg-apply can take that information into account.

Implementation details

• The API is defined in the Y2Security::SecurityPolicies module.
  • Policy represents the security policies. There is one instance for each policy.
  • Rule represents the rules to check. It implements the check and, if possible, the fix to apply.
  • Manager represents a singleton class to manage the policies. Its API allows getting the known policies, enabling or disabling a policy and getting the issues from the enabled policies.

[kobliha]

Looks nice, I'd maybe put those errors under the "STIG is enabled (disable)" similarly as we list, e.g. forwarding details in network-routing. In such case, it would clearly connect that message with the fact that it's caused by that STIG thing.

[mvidner]

Not so stupid question: who is STIG and what are they doing in YaST?!

[mvidner]

I guess it is a Security Technical Implementation Guide but the Wikipedia article is quite vague. I assume we have openSUSE/SLE specific pointers, please add them.

[dgdavid]

Looks nice, I'd maybe put those errors under the "STIG is enabled (disable)" similarly as we list, e.g. forwarding details in network-routing. In such case, it would clearly connect that message with the fact that it's caused by that STIG thing.

I told them the same... but I think it's not possible/straight forward right now.

[yast-bot]

:heavy_check_mark: Internal Jenkins job #5 successfully finished :heavy_check_mark: Created IBS submit request #283897