Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 1856399

Summary: Selinux is stopping logind from creating a /run/systemd/reboot-to-boot-loader-menu file
Product: [Fedora] Fedora Reporter: Hans de Goede <hdegoede>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 33CC: alciregi, bugzilla, dwalsh, grepl.miroslav, lvrabec, mmalik, msekleta, plautrba, vmojzis, yaneti, zbyszek, zpytela
Target Milestone: ---Keywords: Reopened, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-3.14.6-31.fc33 selinux-policy-3.14.6-34.fc33 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-01-17 01:50:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1812955    
Bug Blocks:    

Description Hans de Goede 2020-07-13 14:20:29 UTC
As part of: https://fedoraproject.org/wiki/Changes/CleanupGnomeHiddenBootMenuIntegration#Detailed_Description

I'm working on making grub support the systemd bootloader interface for making:

systemctl reboot --boot-loader-menu=##

Work, see: https://github.com/systemd/systemd/blob/master/docs/ENVIRONMENT.md
(search for "SYSTEMD_REBOOT_TO_BOOT_LOADER_MENU") if you want to know more about this interface.

The way the interface for non sd-boot bootloader works is that logind creates a:
/run/systemd/reboot-to-boot-loader-menu text-file with the desired menu timeout in there.

ATM selinux appears to be denying this:

type=AVC msg=audit(1594649231.332:261): avc:  denied  { create } for  pid=1449 comm="systemd-logind" name=".#reboot-to-loader-menuTiFeuJ" scontext=system_u:system_r:systemd_logind_t:s0 tcontext=system_u:object_r:init_var_run_t:s0 tclass=file permissive=0

Note it looks like logind is creating a temporary file with the correct contents first and then renaming it to the final filename.

I'll retry in permissive mode and see if there are any more AVCs (likely there will be).

Comment 1 Hans de Goede 2020-07-13 14:28:02 UTC
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

Comment 2 Ben Cotton 2020-08-11 13:47:06 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle.
Changing version to 33.

Comment 3 Zdenek Pytela 2020-10-02 16:19:07 UTC
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.

Comment 4 Zbigniew Jędrzejewski-Szmek 2020-10-03 09:36:20 UTC
> 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.

Comment 5 Lukas Vrabec 2020-10-05 12:37:54 UTC
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.

Comment 6 Zdenek Pytela 2020-10-07 09:21:22 UTC
(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.

Comment 7 Hans de Goede 2020-10-07 10:11:13 UTC
(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

Comment 8 Chris Murphy 2020-10-18 05:50:08 UTC
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

Comment 9 Chris Murphy 2020-10-18 05:52:39 UTC
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

Comment 10 Hans de Goede 2020-10-18 09:09:22 UTC
*** Bug 1880159 has been marked as a duplicate of this bug. ***

Comment 11 Michal Sekletar 2020-11-02 13:26:32 UTC
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.

Comment 12 Zdenek Pytela 2020-12-07 21:18:37 UTC
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/497

Comment 13 Zdenek Pytela 2020-12-08 20:02:43 UTC
Backported to F33:
https://github.com/fedora-selinux/selinux-policy/pull/501

Comment 14 Fedora Update System 2020-12-09 14:37:04 UTC
FEDORA-2020-aff0be81b3 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-aff0be81b3

Comment 15 Hans de Goede 2020-12-09 16:17:11 UTC
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?

Comment 16 Fedora Update System 2020-12-11 00:04:16 UTC
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.

Comment 17 Fedora Update System 2020-12-12 01:04:51 UTC
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.

Comment 18 Hans de Goede 2020-12-12 14:49:09 UTC
As I already mentioned this is not fixed, re-opening.

Comment 19 Hans de Goede 2021-01-12 12:22:55 UTC
Hi, any progress on this?

Comment 20 Zdenek Pytela 2021-01-12 14:29:46 UTC
Hans,

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

Comment 21 Fedora Update System 2021-01-15 10:44:33 UTC
FEDORA-2021-6030ff881c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2021-6030ff881c

Comment 22 Fedora Update System 2021-01-16 02:18:01 UTC
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.

Comment 23 Hans de Goede 2021-01-16 12:40:26 UTC
I can confirm that the new update fixes this, thank you.

Comment 24 Fedora Update System 2021-01-17 01:50:04 UTC
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.