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?
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
_______________________________________________
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
