Re: F34 Change proposal: Remove support for SELinux runtime disable (System-Wide Change)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi James,

On Tue, Sep 8, 2020 at 8:43 PM James Cassell
<fedoraproject@xxxxxxxxxxxxx> 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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux