Hi James, On Tue, Sep 8, 2020 at 8:43 PM James Cassell <fedoraproj...@cyberpear.com> wrote: > On Tue, Sep 8, 2020, at 11:28 AM, 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. > I've found certain real-time use cases require SELinux to be disabled to meet > the real time guarantees. (Permissive doesn't help because it's a timing > issue, not permission issue.) I'd argue that when going real-time, you need to use a modified kernel anyway and in that case it should be easier to just disable CONFIG_SECURITY_SELINUX entirely in it. But maybe there can be a situation where you get some 3rd party real-time kernel which has SELinux enabled but it's the only thing breaking the latency for your use case. In that case you'd really need to get SELinux disabled properly. Anyway, SELinux enabled with no policy loaded should be closer to SElinux disabled than to SELinux permissive. In that scenario the hooks are active, but they mostly do almost nothing. There should be very little effect on time spent in syscalls compared to SELinux fully disabled. > > 2. Does this affect resetting the root password with init=/bin/bash and using > `/sbin/load_policy -i` to avoid a relabel? Booting with init=/bin/bash either doesn't currently work on Fedora, or I'm doing it wrong... Anyway, on a system without selinux=0 and with SELINUX=enforcing or =permissive in /etc/selinux/config, it will always be possible to load a policy if it hasn't been loaded yet. Not sure about SELINUX=disabled, but I think it should behave the same as before. (And with selinux=0 it obviously isn't possible neither before, nor after this change.) > > 3. Generally, forcing things to be cmdline options would benefit from a > generic way to configure and manage them, such as using drop-in snippets. > Ideally this would work the same way across BIOS and UEFI systems. It's > difficult to programmatically manipulate GRUB_CMDLINE_LINUX, which is the > current standard configuration method. I agree that kernel cmdline management is a pain on Fedora/Linux, but improving that is beyond what we (the proposal owners and our team) can do :( This is on the shoulders of bootloader maintainers, although I understand that refactoring GRUB/zipl to improve this would likely be a pretty heroic endeavor... I plan to at least add some convenience scripts to the selinux-policy package that would do the "add/remove selinux=0 to/from GRUB_CMDLINE_LINUX and run grub2-mkconfig" dance automatically so that there is still some convenient way of disabling SELinux for those who need it (at least on non-s390x systems). > > Thanks for putting the security-enhancing proposal forward! And thank you for the valuable feedback! -- Ondrej Mosnacek Software Engineer, Platform Security - SELinux kernel Red Hat, Inc. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
