On Fri, Feb 19, 2021 at 5:23 PM Hans de Goede <hdegoede@xxxxxxxxxx> wrote:
> Hi,
>
> On 2/19/21 2:24 PM, Ondrej Mosnacek wrote:
> > Hi Hans,
> >
> > On Fri, Feb 19, 2021 at 1:36 PM Hans de Goede <hdegoede@xxxxxxxxxx> 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
>
> Ah, good TBH I was worried a bit that it was intentional.
>
> I'm happy to hear that it was unintentional and a fix is on its way.
>
> > - 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
>
> Thank you for the detailed explanation.
>
> > 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.
>
> Sounds good, I look forward to being able to turn enforcing back on.
>
> ###
>
> Unrelated, while looking at audit.log to get info sending my original email
> I also noticed multiple of these lockdown related AVC lines:
>
> type=AVC msg=audit(1613257073.100:186): avc: denied { integrity } for pid=647 comm="systemd-logind" lockdown_reason="hibernation" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=lockdown permissive=1
>
> Note this is on a system with secure-boot disabled. Known issue or should I file a bug for this?
>
> ###
>
> While at it, I've also gone over audit.log for more AVCs in F34 and found a whole bunch of "denied { watch } ..." AVCs:
>
> type=AVC msg=audit(1613257064.658:130): avc: denied { watch } for pid=515 comm="avahi-daemon" path="/services" dev="mmcblk1p4" ino=1175311 scontext=system_u:system_r:avahi_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=1
>
> type=AVC msg=audit(1613257065.502:152): avc: denied { watch } for pid=640 comm="accounts-daemon" path="/etc/gdm" dev="mmcblk1p4" ino=1175113 scontext=system_u:system_r:accountsd_t:s0 tcontext=system_u:object_r:xdm_etc_t:s0 tclass=dir permissive=1
>
> type=AVC msg=audit(1613257067.416:177): avc: denied { watch } for pid=723 comm="dbus-daemon" path="/etc/dbus-1/session.d" dev="mmcblk1p4" ino=1175380 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:dbusd_etc_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1613257067.809:178): avc: denied { watch } for pid=724 comm="gnome-session-b" path="/run/systemd/sessions" dev="tmpfs" ino=68 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1613257071.851:179): avc: denied { watch } for pid=758 comm="gnome-shell" path="/var/lib/gdm/.config" dev="mmcblk1p4" ino=262217 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1613257071.851:180): avc: denied { watch } for pid=758 comm="gnome-shell" path="/etc/xdg" dev="mmcblk1p4" ino=1175203 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1613257071.863:181): avc: denied { watch } for pid=758 comm="gnome-shell" path="/var/lib/flatpak" dev="mmcblk1p4" ino=262080 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=1
>
> type=AVC msg=audit(1613257074.278:187): avc: denied { watch } for pid=867 comm="gmain" path="/etc" dev="mmcblk1p4" ino=1175041 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=1
> type=AVC msg=audit(1613257074.322:188): avc: denied { watch } for pid=870 comm="gsd-sound" path="/var/lib/gdm/.local/share/sounds" dev="mmcblk1p4" ino=265134 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:xdm_var_lib_t:s0 tclass=dir permissive=1
>
> type=AVC msg=audit(1613257075.986:196): avc: denied { watch } for pid=758 comm="gnome-shell" path="/var/lib/AccountsService/icons" dev="mmcblk1p4" ino=262116 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:accountsd_var_lib_t:s0 tclass=dir permissive=1
>
> Are these known issue(s) or should I file a bug(s) for this?
Some of those look familiar and likely already have BZs reported and a
few of them might be fixed in git already... but I'll defer to Zdenek,
who probably has a better overview of the current bugs.
>
> IF you want bug(s) for this can you let me know if I should split these over multiple bugs ?
>
> And if you want them split can you know how you want them grouped ?
>
> Regards,
>
> Hans
>
--
Ondrej Mosnacek
Software Engineer, Linux 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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
