On Wed, Sep 16, 2020 at 04:07:11PM +0200, Ondrej Mosnacek wrote: > On Thu, Sep 10, 2020 at 6:05 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > > > Ondrej Mosnacek <omosnace@xxxxxxxxxx> writes: > > > > > James Cassell wrote: > > >> Ben Cotton wrote: > > >> > > >>> https://fedoraproject.org/wiki/Changes/Remove_Support_For_SELinux_Runtime_Disable > > >>> > > >>> == Summary == > > >>> Remove support for SELinux runtime disable so that the LSM hooks can > > >>> be hardened via read-only-after-initialization protections. > > >>> > > >>> Migrate users to using ''selinux=0'' if they want to disable SELinux. > > >> > > >> I like the proposal. A few thoughts and questions, though: > > >> > > >> 1. I think systems with SELINUX=disabled without selinux=0 should > > >> hard fail very loudly. > > > > > > That's an interesting opinion... It would be easier and more direct to > > > do it that way, but we are worried that users would complain that > > > their SELINUX=disabled setup is suddenly broken and they need to mess > > > with the bootloader to get a working system again. (I don't know that > > > much about real-time systems, so feel free to correct/enlighten me > > > here.) That's why we try to make sure that things keep working > > > more-or-less the same as before. > > > > Please correct me if I'm wrong, but *aren't* those systems broken? That > > is, if an admin sets selinux=disabled on a system after this change has > > (hypothetically) gone through, won't they have a system in which selinux > > isn't disabled? Or is there going to be migration logic in perpetuity? > > I wouldn't say they are broken. They rely on a feature that has been a > supported and kind-of standard way to disable SELinux until now. After > this proposal would be implemented, they would still get a state that > is very close to SELinux being disabled, so I don't think we need to > go as far as e.g. refusing to boot with such configuration. And btw, even current /etc/selinux/config describes the future situation: # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. ^^ this is exactly what will happen when this change is accepted. SELinux will be enabled internally in kernel but no policy will be loaded and as it was already explained, for user this situation should be almost the same as SELinux disabled. The difference will be only in kernel internal level. > Of course, it would be great if we could somehow alert the sysadmin > that they should change their configuration if they have > SELINUX=disabled in /etc/selinux/config but no selinux=0 on kernel > cmdline, but I'm not sure if there is an established way to do that in > Fedora (other than documenting such things in Release notes). On RHEL, > this is possible via LEAPP or Red Hat Insights, but what can you do > on Fedora? Printing warnings/errors anywhere is not reliable, because > the system (or even a cluster of systems) may be managed only remotely > with the admin logging in only when something breaks. Or is there some > established way of telling the admin: "Hey, your system may not seem > broken, but there is this configuration issue that needs your > attention."? > Maybe we could add a oneshot systemd unit which would warn users when /etc/selinux/config contains SELINUX=disabled but it's not disabled in kernel. Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx