Hi Hans,
On Fri, Feb 19, 2021 at 1:36 PM Hans de Goede <hdego...@redhat.com> wrote:
> Hi All,
>
> While dogfooding F34 I noticed that out of tree kernel modules (1) are
> now being blocked, not by the kernel's lockdown mechanism (which only
> does this when secureboot is enabled) but by selinux:
>
> audit: type=1400 audit(1613736626.937:95): avc: denied { integrity } for
> pid=401 comm="systemd-udevd" lockdown_reason="unsigned module loading"
> scontext=system_u:system_r:udev_t:s0-s0:c0.c1023
> tcontext=system_u:system_r:udev_t:s0-s0:c0.c1023 tclass=lockdown permissive=1
>
> Note as you can see I've put selinux in permissive mode and that
> fixes the unsigned module loading, showing that this is indeed
> caused by some new selinux rules.
>
> I must say that this seems like a bad idea, we already have the kernel
> enforcing module-loading lockdown stuff, we really do not need selinux to
> add extra enforcement on top of this, esp. not enforcement which seems
> to circumvent the usual "disable secure boot" workaround.
Yes, it was unintentional - we introduced the lockdown class (which
mimics the lockdown mechanism, but works on per-SELinux-domain basis)
into the Fedora policy with [1], but this was one of the things not
found by initial testing. We didn't mean to introduce any regressions,
just limit the new permissions only to domains that actually need
them.
This particular issue is already fixed in git (as of a few days ago):
https://github.com/fedora-selinux/selinux-policy/commit/fee95c0434ade64c14add7f07233eb44f396262b
And the permission will be allowed also to unconfined_t, which is the
type that user sessions will get by default (under the "targeted"
policy), so also e.g. manual modprobe from terminal should still work:
https://github.com/fedora-selinux/selinux-policy/commit/e4ea1e13059ac475c3f012a3f58cbf0b0e554164
The fixes should propagate into F34 and Rawhide soon.
[1]
https://fedoraproject.org/wiki/Changes/Make_selinux_policy_uptodate_with_current_kernel
>
> I believe this is a bad idea for 2 reasons
>
> 1. Whether we like it or not sometimes our users want to use /
> have a need for external kernel modules. This is incompatible with
> secure-boot. Which is meh, but understandable since we should not
> allow loading unsigned kernel-code when secure-boot is used and
> external modules are by definition unsigned.
>
> But now we are breaking the usual (already a bit sucky)
> "disable secure-boot in your BIOS" workaround by adding another hoop
> to jump through, this is IMHO a really bad idea.
>
> 2. It makes using Fedora for kernel development harder, well at least
> it will make kernel developers like me just put selinux in permissive
> mode (at which point I might just as well disable it) As a frequent
> dog-fooder of recent Fedora versions, while running in enforcing mode,
> I'm know to regularly report selinux policy issues. This feedback will
> be lost now ...
>
> Regards,
>
> Hans
>
>
>
>
>
>
> 1) Not really an out-of-tree module actually, I saw the when copying
> an individual .ko file from my build-machine to the target-machine,
> so without going through make modules_install and thus without it
> being signed with my local signing-key. But out-of-tree modules will
> hit the same issue
> _______________________________________________
> 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
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
--
Ondrej Mosnacek
Software Engineer, Linux 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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
