Bug 2291173 - Logging in via gdm doesn't work for staff_u unless staff_dbusd_t is made permissive
Summary: Logging in via gdm doesn't work for staff_u unless staff_dbusd_t is made perm...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 40
Hardware: Unspecified
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2024-06-10 13:52 UTC by Sam Morris
Modified: 2024-11-05 04:42 UTC (History)
7 users (show)

Fixed In Version: selinux-policy-40.29-2.fc40
Clone Of:
Environment:
Last Closed: 2024-11-05 04:42:46 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 2369 0 None open Update policy for xdm with confined users 2024-10-02 11:24:21 UTC

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.


Note You need to log in before you can comment on or make changes to this bug.