Bug 2291173

Summary: Logging in via gdm doesn't work for staff_u unless staff_dbusd_t is made permissive
Product: [Fedora] Fedora Reporter: Sam Morris <sam>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 40CC: dwalsh, lvrabec, mmalik, omosnacek, pkoncity, vmojzis, zpytela
Target Milestone: ---Keywords: SELinux
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-40.29-2.fc40 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-11-05 04:42:46 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Sam Morris 2024-06-10 13:52:04 UTC
After logging in via GDM as a user mapped to staff_u I get a blue screen (which is a quirk of my monitor, basically it's what happens when there's no video output).

The system is fully functional, I can SSH in, etc., but GDM and/or my login session are stuck in a way that prevents Ctrl-Alt-Fn keys from switching  virtual consoles, giving the appearance of a crashed system.

If I run 'semanage permissive -a staff_dbusd_t' then I can log in fine.

After doing so, "ausearch -i -m avc -se staff_dbusd_t" shows two sets of events:

type=AVC msg=audit(10/06/24 12:26:17.286:3657) : avc:  denied  { execute } for  pid=302496 comm=dbus-daemon name=at-spi-bus-launcher dev="dm-1" ino=4077266 scontext=staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:gnome_atspi_exec_t:s0 tclass=file permissive=0

and:

type=AVC msg=audit(10/06/24 12:45:54.010:687) : avc:  denied  { watch } for  pid=12716 comm=dbus-broker-lau path=/var/lib/flatpak/exports/share/dbus-1/services dev="dm-0" ino=2174243 scontext=staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=dir permissive=0 

I can't say if either of these are the direct cause of the problem, or whether they're just symptoms caused by other failures when when staff_dbusd_t is not in enforcing mode. I can try again with dontaudit rules disabled and report back if helpful.

Paging through journalctl output I see the second message is associated with:

Jun 10 12:51:48 dbus-broker-launch[14538]: ERROR dirwatch_add @ ../src/util/dirwatch.c +122: Permission denied
Jun 10 12:51:48 dbus-broker-launch[14538]:       launcher_load_service_dir @ ../src/launch/launcher.c +770
Jun 10 12:51:48 dbus-broker-launch[14538]:       launcher_load_standard_session_services @ ../src/launch/launcher.c +916
Jun 10 12:51:48 dbus-broker-launch[14538]:       launcher_load_services @ ../src/launch/launcher.c +972
Jun 10 12:51:48 dbus-broker-launch[14538]:       launcher_run @ ../src/launch/launcher.c +1341
Jun 10 12:51:48 dbus-broker-launch[14538]:       run @ ../src/launch/main.c +152
Jun 10 12:51:48 audit[14538]: AVC avc:  denied  { watch } for  pid=14538 comm="dbus-broker-lau" path="/var/lib/flatpak/exports/share/dbus-1/services" dev="dm-0" ino=2174243 scontext=staff_u:staff_r:staff_dbusd_t:s0-s0:c0.c1023 tcontext=s>
Jun 10 12:51:48 systemd[14458]: dbus-broker.service: Main process exited, code=exited, status=1/FAILURE

... which is repeated several times. Preventing dbus-broker from launching sounds like the sort of thing that would explain why a graphical login would fail.

Reproducible: Always

Steps to Reproduce:
1. Create a user mapped to staff_u
2. Log in via GDM
Actual Results:  
Blue screen (login process is getting stuck somewhere while video output is disabled)

Expected Results:  
Successful login

Comment 1 Sam Morris 2024-06-10 14:18:04 UTC
Tried this on a second system with totally different hardware and after authenticating the muse pointer freezes and I can't switch virtual consoles; however I can SSH in to run 'semanage permissive -a staff_dbusd_t', after which I can log in OK.

So it's not a hardware problem but an SELinux policy problem.

Comment 2 Sam Morris 2024-06-10 14:22:38 UTC
Likely /var/lib/flatpak/exports/share/dbus-1/services needs to be given a suitable label and rules are needed to allow staff_dbusd_t/sysadm_dbusd_t/user_dbusd_t/xguest_dbusd_t to access it.

I guess adding rules to allow those types to execute gnome_atspi_exec_t is also needed, do you want me to file separate bugzillas for that?

Comment 3 Zdenek Pytela 2024-06-10 14:35:25 UTC
(In reply to Sam Morris from comment #2)
> I guess adding rules to allow those types to execute gnome_atspi_exec_t is
> also needed, do you want me to file separate bugzillas for that?
No, this is sufficient, thank you.
It will probably take me more than 1 build to have it addressed completely.

Comment 4 Fedora Update System 2024-10-26 12:02:09 UTC
FEDORA-2024-aa24e6024f (selinux-policy-40.29-1.fc40) has been submitted as an update to Fedora 40.
https://bodhi.fedoraproject.org/updates/FEDORA-2024-aa24e6024f

Comment 5 Fedora Update System 2024-10-28 03:49:52 UTC
FEDORA-2024-a9588c99c1 has been pushed to the Fedora 40 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-a9588c99c1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-a9588c99c1

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

Comment 6 Fedora Update System 2024-11-05 04:42:46 UTC
FEDORA-2024-a9588c99c1 (selinux-policy-40.29-2.fc40) has been pushed to the Fedora 40 stable repository.
If problem still persists, please make note of it in this bug report.