As promised here are all the denials after switching to permissive mode:

type=AVC msg=audit(1594650178.381:286): avc:  denied  { create } for  pid=1449 comm="systemd-logind" name=".#reboot-to-loader-menud4JAeK" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1594650178.381:287): avc:  denied  { read write open } for  pid=1449 comm="systemd-logind" path="/run/systemd/.#reboot-to-loader-menud4JAeK" dev="tmpfs" ino=192171 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1594650178.381:288): avc:  denied  { getattr } for  pid=1449 comm="systemd-logind" path="/run/systemd/.#reboot-to-loader-menud4JAeK" dev="tmpfs" ino=192171 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1594650178.382:289): avc:  denied  { setattr } for  pid=1449 comm="systemd-logind" name=".#reboot-to-loader-menud4JAeK" dev="tmpfs" ino=192171 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1594650178.382:290): avc:  denied  { rename } for  pid=1449 comm="systemd-logind" name=".#reboot-to-loader-menud4JAeK" dev="tmpfs" ino=192171 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1

This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Hans,

Thank you for adding all the details. Current status is as follows:

There already was a transition for a generic file which was reverted later, so we need to proceed carefully.

commit 558082db5a3f5d30c4c819c2c19dad32669f9924
Author: Lukas Vrabec <lvrabec>
Date:   Thu Feb 25 19:21:51 2016 +0100

    Allow systemd-logind to create .#nologinXXXXXX labeled as systemd_logind_var_run_t in /var/run/systemd/ rhbz#1285019

commit 03966d729c9daba11f4f27e1876d2695fa71cfe0
Author: Lukas Vrabec <lvrabec>
Date:   Fri Feb 26 14:05:01 2016 +0100

    Revert "Allow systemd-logind to create .#nologinXXXXXX labeled as systemd_logind_var_run_t in /var/run/systemd/ rhbz#1285019"
    

Currently we have these runtime files transitions for systemd-logind:

init_named_pid_filetrans(systemd_logind_t, systemd_logind_sessions_t, dir, "sessions")
init_named_pid_filetrans(systemd_logind_t, systemd_logind_inhibit_var_run_t, dir, "inhibit")
init_named_pid_filetrans(systemd_logind_t, systemd_networkd_var_run_t, dir, "netif")
init_pid_filetrans(systemd_logind_t, systemd_logind_var_run_t, dir)

files_pid_filetrans(systemd_logind_t, systemd_logind_var_run_t, file)

The unpredictable filename is troublesome; this bz would resolve better if it was e. g. created in a directory with a fixed name.

> The unpredictable filename is troublesome; this bz would resolve better if it was e. g. created in a directory with a fixed name.

The directory is always /run/systemd. The filename is unpredictable because we want to use
generic code which atomically replaces the destination file with new contents. In this case
the directory is owned by root and there are no concurrent writers to that file, so we in
principle we could use a predictable file name. But that'd require special-casing this
our code and would be generally super ugly.

Hi Hans, 

Are you still able to reproduce it? Can you share not only AVC type of audit msg but also SELINUX_ERR ? 

Just please reproduce the issue and then attach output of:

# ausearch -m AVC,SELINUX_ERR,USER_AVC -ts today

Thanks,
Lukas.

(In reply to Zbigniew Jędrzejewski-Szmek from comment #4)
> > The unpredictable filename is troublesome; this bz would resolve better if it was e. g. created in a directory with a fixed name.
> 
> The directory is always /run/systemd. The filename is unpredictable because
> we want to use
> generic code which atomically replaces the destination file with new
> contents. In this case
> the directory is owned by root and there are no concurrent writers to that
> file, so we in
> principle we could use a predictable file name. But that'd require
> special-casing this
> our code and would be generally super ugly.

Zbyszek,

/run/systemd/ is a directory filled with various data types and shared by many distinct services. What I had in mind was a directory name like /run/systemd/loader with a private selinux type (different to all those others), then dealing with any filename inside is seamless.

(In reply to Lukas Vrabec from comment #5)
> Hi Hans, 
> 
> Are you still able to reproduce it? Can you share not only AVC type of audit
> msg but also SELINUX_ERR ? 
> 
> Just please reproduce the issue and then attach output of:
> 
> # ausearch -m AVC,SELINUX_ERR,USER_AVC -ts today
> 
> Thanks,
> Lukas.

Hi Lukas,

I'm sorry but I'm a bit swamped with my new responsibilities as pdx86 kernel subsystem maintainer atm (I just started in this role because the previous maintainer did not have time anymore and there is a large backlog to get through).

You should be able to easily reproduce this problem yourself, take a recent F33 install and run:

systemctl reboot --boot-loader-menu=60

If you run that after a "setenforce 0" the bootloader menu should show for 60 seconds on the next boot; and you should get all related selinux denials logged.

Please let me know if you need more info/input ideally this should be fixed before F33 final.

Regards,

Hans

It's still a problem with selinux-policy-3.14.6-28.fc33.noarch

time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.960:267): avc:  denied  { rename } for  pid=710 comm="systemd-logind" name=".#reboot-to-boot-loader-menu2x8N7R" dev="tmpfs" ino=53813 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
----
time->Sat Oct 17 23:35:56 2020
type=AVC msg=audit(1602999356.046:252): avc:  denied  { create } for  pid=708 comm="systemd-logind" name=".#reboot-to-boot-loader-menuQDjIkI" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0

See also bug 1880159

Oops, bad paste. This is everything for one event, with setenforce 0.


time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.959:263): avc:  denied  { create } for  pid=710 comm="systemd-logind" name=".#reboot-to-boot-loader-menu2x8N7R" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
----
time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.959:264): avc:  denied  { read write open } for  pid=710 comm="systemd-logind" path="/run/systemd/.#reboot-to-boot-loader-menu2x8N7R" dev="tmpfs" ino=53813 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
----
time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.959:265): avc:  denied  { getattr } for  pid=710 comm="systemd-logind" path="/run/systemd/.#reboot-to-boot-loader-menu2x8N7R" dev="tmpfs" ino=53813 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
----
time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.960:266): avc:  denied  { setattr } for  pid=710 comm="systemd-logind" name=".#reboot-to-boot-loader-menu2x8N7R" dev="tmpfs" ino=53813 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
----
time->Sat Oct 17 23:34:36 2020
type=AVC msg=audit(1602999276.960:267): avc:  denied  { rename } for  pid=710 comm="systemd-logind" name=".#reboot-to-boot-loader-menu2x8N7R" dev="tmpfs" ino=53813 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1

*** Bug 1880159 has been marked as a duplicate of this bug. ***

systemd-logind can already create files in /run and directories under /run/systemd. It seems that it is missing permissions to also create *files* under /run/systemd/. I think we should be able to allow this w/o any negative effects to overall system security provided by SELinux.

I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/497

Backported to F33:
https://github.com/fedora-selinux/selinux-policy/pull/501

FEDORA-2020-aff0be81b3 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3

Thank you, unfortunately selinux-policy-3.14.6-31.fc33 does not seem to fix this for me, I still need to do "setenforce 0" for the reboot into boot-loader-menu feature to work.

I double checked I'm running the selinux-policy from FEDORA-2020-aff0be81b3:

[hans@x1 ~]$ rpm -qa | grep selinux-policy
selinux-policy-3.14.6-31.fc33.noarch
selinux-policy-targeted-3.14.6-31.fc33.noarch

And here are the denied lines from audit.log when rebooting into the boot-loader-menu after doing "setenforce 0":

type=MAC_STATUS msg=audit(1607530113.524:226): enforcing=0 old_enforcing=1 auid=1000 ses=3 enabled=1 old-enabled=1 lsm=selinux res=1 AUID="hans"
type=AVC msg=audit(1607530119.568:231): avc:  denied  { create } for  pid=1329 comm="systemd-logind" name=".#reboot-to-boot-loader-menux0dnOH" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1607530119.569:232): avc:  denied  { read write open } for  pid=1329 comm="systemd-logind" path="/run/systemd/.#reboot-to-boot-loader-menux0dnOH" dev="tmpfs" ino=2727 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1607530119.569:233): avc:  denied  { getattr } for  pid=1329 comm="systemd-logind" path="/run/systemd/.#reboot-to-boot-loader-menux0dnOH" dev="tmpfs" ino=2727 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1607530119.569:234): avc:  denied  { setattr } for  pid=1329 comm="systemd-logind" name=".#reboot-to-boot-loader-menux0dnOH" dev="tmpfs" ino=2727 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1
type=AVC msg=audit(1607530119.569:235): avc:  denied  { rename } for  pid=1329 comm="systemd-logind" name=".#reboot-to-boot-loader-menux0dnOH" dev="tmpfs" ino=2727 scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=1

Also I don't see the relevant change in the rpm changelog, so maybe the pull did not make it into this build? :

[hans@x1 ~]$ rpm -q --changelog selinux-policy 
selinux-policy-3.14.6-31.fc33.noarch
* Mon Dec 07 2020 Zdenek Pytela <zpytela> - 3.14.6-31
- Set correct default file context for /usr/libexec/pcp/lib/*
- Add default file context for /usr/libexec/pcp/lib/*
- Update targetd nfs & lvm
- Add interface rpc_manage_exports
- Allow varnish map its private tmp files
- Allow cups_pdf_t domain to communicate with unix_dgram_socket
- Set default file context for /var/lib/ipsec/nss

?

I won't give the update negative karma, because I assume you want to move ahead with the other fixes, but perhaps remove this bug from the bodhi-update for this?

FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-aff0be81b3`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2020-aff0be81b3 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.

As I already mentioned this is not fixed, re-opening.

Hi, any progress on this?

Hans,

The fix is available and will be a part of the next build.

FEDORA-2021-6030ff881c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6030ff881c

FEDORA-2021-6030ff881c has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-6030ff881c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6030ff881c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I can confirm that the new update fixes this, thank you.

FEDORA-2021-6030ff881c has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.