|
Bugzilla – Full Text Bug Listing |
| Summary: | security: when enabling SELinux during install apparmor is still present | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Ludwig Nussel <lnussel> |
| Component: | YaST2 | Assignee: | E-mail List <yast2-maintainers> |
| Status: | RESOLVED FEATURE | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | dgonzalez, jreidinger, llzhao, lnussel, msvec, petr.vorel |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| See Also: |
https://bugzilla.suse.com/show_bug.cgi?id=1194332 https://bugzilla.suse.com/show_bug.cgi?id=1196274 |
||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Ludwig Nussel
2021-08-18 14:05:03 UTC
Frankly, that would be a feature request as the current implementation comes from another feature request (for SELinux) that wanted to have it exactly like this. Especially as TW is SLE 15 SP4 for us - we can't maintain two development branches at the same time. Hi Ludwig! To add a little bit more context, let me clarify to future readers that, as long as the product allows it, the SELinux mode can be configured during the installation through the recently added security client (see screenshots at [1]). Setting it to "Disabled" means to not use SELinux as Linux Security Module but keep using the "default" one (AppArmor in our case, see [2]). That said, if I understood you correctly, you're proposing to give the user the possibility to select the desired LSM (AppArmor, SELinux, or even none) directly from this client. I.e., having a "Linux Security Module" selector which those options and updating the "security", "apparmor", and "selinux" boot params accordingly in addition to select the needed security pattern(s). Right? If so, it sounds more like a feature request than an issue. @Josef, what do you think? Is it feasible? If not, please let me know where I got lost :) Thanks! [1] https://github.com/yast/yast-installation/pull/906 [2] https://github.com/yast/yast-security/pull/83 (In reply to David Diaz from comment #2) > > If so, it sounds more like a feature request than an issue. @Josef, what do > you think? Is it feasible? > > If not, please let me know where I got lost :) > I mean, If so, it sounds more like a feature request than an issue. If not, please let me know where I got lost :) @Josef, what do you think? Is it feasible? yes, for me it makes sense to allow in security to pick and possibly fine tune LSM, but I think this should really go thrue jira with proper discussion, so hopefully we can prevent issues we have after implementing that selinux jira entry. Looking at the feature request (https://jira.suse.com/browse/PM-2244) it doesn't specify what is supposed to happen with Apparmor at all. The feature originated in MicroOS which I suppose doesn't have Apparmor on the medium. So actually it wouldn't be dragged in on MicroOS. All good there. My guess is that PM is not aware that the side effect of the way this feature is implemented would be having both Apparmor and SELinux packages on the system for TW and probably SLE itself when enabling SELinux during installation. (In reply to Josef Reidinger from comment #4) > yes, for me it makes sense to allow in security to pick and possibly fine > tune LSM, but I think this should really go thrue jira with proper > discussion, so hopefully we can prevent issues we have after implementing > that selinux jira entry. This is definitely a reasonable suggestion and I agree would be nice to have. Josef, David, can you please create a Jira request for 15 SP4? TiA! I've created a feature request https://jira.suse.com/browse/PM-2920 Please add your comment there. FYI: there is not just AppArmor and SELinux, we support more LSM modules (at least IMA/EVM). Please when change LSM related kernel boot parameters keep that in mind and try to retest all LSM modules we support (changes driven by this initiative caused #1194332 and #1196274). |