action #89104
Updated by riafarov about 3 years ago
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](https://en.wikipedia.org/wiki/Security-Enhanced_Linux) (aka SELinux) can be now proposed as a major [**L**inux **S**ecurity **M**odule](https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html) 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](https://github.com/yast/yast-security/pull/82#discussion_r567817487)).
Among a bunch of changes, a new [`Y2Security::Selinux`](https://github.com/yast/yast-security/blob/86ffcaec16d24d502b98c33147e3928e5ea982fe/src/lib/y2security/selinux.rb) backend class, responsible to set needed boot kernel params for each mode and write the configuration, and new [proposal](https://github.com/yast/yast-installation/blob/43449edb45aaccc165a62ce14b3dc1d4dbbb36ac/src/lib/installation/clients/security_proposal.rb) and [finish](https://github.com/yast/yast-installation/blob/master/src/lib/installation/clients/security_finish.rb) 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](https://github.com/yast/yast-firewall/blob/SLE-15-SP2/src/lib/y2firewall/widgets/proposal.rb))
All this goes with an increase in test coverage of touched repos :tada:. E.g, [+2.0% in yast-installation](https://coveralls.io/builds/37451553) and [+4.4% in yast-security](https://coveralls.io/github/yast/yast-security?branch=add-selinux-settings-master).
**Fun fact:** Did you know that SELinux was [originally developed by **NSA**](https://www.nsa.gov/news-features/press-room/Article/1637367/national-security-agency-shares-security-enhancements-to-linux/)? :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](https://github.com/yast/skelcd-control-SMO/pull/7/files). 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](https://trello.com/c/g94xQBDM/2159-8-musthave-selinux-and-security-refac#comment-6013d403822b661b1dcb4282)
* The kernel boot params precedence [is a sort of black magic](https://github.com/yast/yast-security/pull/82#discussion_r568495981) (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