Description of problem: selinux-policy-34.1.26-1.el9 prevents KDE from starting. I have tried all the other selinux-policy packages, and it is 34.1.26 specifically that is causing the problem. If I downgrade to selinux-policy-34.1.25-1.el9 everything works, bump it back up to 34.1.26, and things don't work. Version-Release number of selected component (if applicable): selinux-policy-34.1.26-1.el9 selinux-policy-targeted-34.1.26-1.el9 How reproducible: 100% Steps to Reproduce: 1. Enable EPEL - https://docs.fedoraproject.org/en-US/epel/#_el9 2. dnf install https://kojihub.stream.centos.org/kojifiles/packages/google-noto-fonts/20201206/3.el9/noarch/google-noto-sans-mono-fonts-20201206-3.el9.noarch.rpm 3. dnf --enablerepo=epel-testing group install kde-desktop 4. (if needed) systemctl set-default graphical.target 5. reboot 6. # graphically login to Plasma (X11) or Plasma (Wayland) Actual results: You get a crash window that says "We are sorry, ksplashqml closed unexpectedly", you might also get crash windows for one or two other kde related programs. Clicking "Close" or "Restart Application" just makes the window go away for a moment before appearing again. Expected results: Login and the graphical interface starts correctly Additional info: Doing a "journal -f" (on a ssh login) shows the following during login --- Feb 24 14:59:11 cs9 setroubleshoot[1427]: AnalyzeThread.run(): Cancel pending alarm Feb 24 14:59:11 cs9 setroubleshootd[1648]: eu-readelf: cannot open input file '/memfd:JITCode:QtQml (deleted)': No such file or directory Feb 24 14:59:11 cs9 setroubleshoot[1427]: SELinux is preventing ksplashqml from execmod access on the file /memfd:JITCode:QtQml (deleted). For complete SELinux messages run: sealert -l 267f3b75-f273-42be-ab3c-95c418648121 Feb 24 14:59:11 cs9 setroubleshoot[1427]: SELinux is preventing ksplashqml from execmod access on the file /memfd:JITCode:QtQml (deleted). ***** Plugin allow_execmod (53.1 confidence) suggests ********************* If this issue occurred during normal system operation. Then this alert could be a serious issue and your system could be compromised. Setroubleshoot examined '/memfd:JITCode:QtQml.(deleted)' to make sure it was built correctly, but can not determine if this application has been compromised. Do contact your security administrator and report this issue ***** Plugin catchall_boolean (42.6 confidence) suggests ****************** If you want to allow selinuxuser to execmod Then you must tell SELinux about this by enabling the 'selinuxuser_execmod' boolean. Do setsebool -P selinuxuser_execmod 1 ***** Plugin catchall (5.76 confidence) suggests ************************** If you believe that ksplashqml should be allowed execmod access on the memfd:JITCode:QtQml (deleted) file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'ksplashqml' --raw | audit2allow -M my-ksplashqml # semodule -X 300 -i my-ksplashqml.pp
Troy, Can you attach audited denials? # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
Created attachment 1863321 [details] Audited Denials Audited Denials attached
Unfortunately details are missing, but it is clear that there is only one permission requested: ---- type=AVC msg=audit(02/25/2022 06:38:49.592:157) : avc: denied { execmod } for pid=1867 comm=kscreenlocker_g path=/memfd:JITCode:QtQml (deleted) dev="tmpfs" ino=2148 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0 The solution would probably consist of assigning a private type to /memfd: objects and allowing execmod with some new boolean enabled. Currently there is: SELinux boolean State Default Description xserver_execmem (off , off) Allows XServer to execute writable memory selinuxuser_execmod (off , off) Allow all unconfined executables to use libraries requiring text relocation that are not labeled textrel_shlib_t
*** Bug 2059399 has been marked as a duplicate of this bug. ***
Is there anything I can do to help get this fixed in time for RHEL 9 GA? I really really ... really don't want to have to say "Just turn off selinux" I have tested selinux-policy-34.1.27-1.el9 with the same failed results.
(In reply to Troy Dawson from comment #5) > Is there anything I can do to help get this fixed in time for RHEL 9 GA? Please raise the exception flag and provide justification.
Please grant this bug an exception so that it can be in RHEL 9.0 GA release. KDE is not a Red Hat supported product. It is in EPEL 8 and 9, and community supported. But many customers, and Red Hatters, have requested it be available in EPEL 9 when RHEL 9.0 is released. The epel community has worked hard to get epel9, and the KDE Plasma Desktop ready and available for the RHEL 9.0 launch. We would like this launch to be as smooth as possible, and having an selinux stumble at the very first would not be good. It's KDE that is seeing this problem with xserver and wayland now. But it's possible that other customer applications might run into the same problem. Final reason for the exception. Although it is possible to have the selinux-policy fix come out as a day 1 update, it would not be a good thing. That would mean that for the next 6 months, and longer, we would have to have special pages written telling what the errors means, and instructions telling what to do. More important than the fact that it would be work for me and others, it would give selinux yet another punch that it doesn't need. It's taken many years to get selinux to the point where people don't just turn it off. It works and it's policies cover most everything an average user would do. I don't want to have to write instruction saying that one way to get your KDE desktop started initially is to temporarily turn selinux off.
(In reply to Troy Dawson from comment #5) > Is there anything I can do to help get this fixed in time for RHEL 9 GA? > > I really really ... really don't want to have to say "Just turn off selinux" This is not at all necessary. The change brought by the previous release was a default value of the selinuxuser_execmod boolean, so it is sufficient to run: # setsebool -P selinuxuser_execmod 1 The suggestion is already in the output of setroubleshoot in #c0.
(In reply to Zdenek Pytela from comment #11) > (In reply to Troy Dawson from comment #5) > > Is there anything I can do to help get this fixed in time for RHEL 9 GA? > > > > I really really ... really don't want to have to say "Just turn off selinux" > > This is not at all necessary. The change brought by the previous release was > a default value of the selinuxuser_execmod boolean, so it is sufficient to > run: > > # setsebool -P selinuxuser_execmod 1 > > The suggestion is already in the output of setroubleshoot in #c0. I totally missed that, thank you. I feel better about putting that in my instructions for my testers. But if possible, I would still like to get this fixed by RHEL 9.0 GA.
(In reply to Zdenek Pytela from comment #3) > Unfortunately details are missing, but it is clear that there is only one > permission requested: > > ---- > type=AVC msg=audit(02/25/2022 06:38:49.592:157) : avc: denied { execmod } > for pid=1867 comm=kscreenlocker_g path=/memfd:JITCode:QtQml (deleted) > dev="tmpfs" ino=2148 > scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > tcontext=unconfined_u:object_r:user_tmp_t:s0 tclass=file permissive=0 > > The solution would probably consist of assigning a private type to /memfd: > objects and allowing execmod with some new boolean enabled. Troy, do you happen to know which process creates the /memfd: objects and which other services may also need the access?
Starting up with selinuxuser_execmod 0, I see only two services ksplashqml and plasmashell. Because plasmashell cannot start, nothing else starts. When change to selinuxuser_execmod 1 and log in, then dig through /proc/ I see the following have links to /memfd:<something> (deleted) <something> is different for each process ksplashqml plasmashell kactivitymanagerd pipewire (alot of them listed in one process) dbus-broker firewalld
(In reply to Troy Dawson from comment #14) > Starting up with selinuxuser_execmod 0, I see only two services ksplashqml > and plasmashell. > Because plasmashell cannot start, nothing else starts. > > When change to selinuxuser_execmod 1 and log in, then dig through /proc/ I > see the following have links to /memfd:<something> (deleted) > <something> is different for each process So neither of the files is shared between processes? I don't know if there is a way to figure it out, but is execmod required for all of them? In the permissive mode, no other denials appear? > ksplashqml > plasmashell > kactivitymanagerd > pipewire (alot of them listed in one process) I cannot confirm ksplash*, but suppose that as the other it runs in the SELinux user domain. > dbus-broker This can be either system or user session. > firewalld It has its own domain, but does it need access to the same filedescriptor which is used by plasma? Please run: ps -eo pid,ppid,command,context | grep -e CONTEXT -e ksplash -e dbus
ksplash only shows up at startup, so I had to log out and in a few times to catch it. Here is the output during login. PID PPID COMMAND CONTEXT 767 1 /usr/bin/dbus-broker-launch system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 772 767 dbus-broker --log 4 --contr system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 3466 3453 /usr/bin/dbus-broker-launch unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3467 3466 dbus-broker --log 4 --contr unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3550 3509 /usr/bin/dbus-broker-launch unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3551 3550 dbus-broker --log 4 --contr unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3576 3528 /usr/bin/ksplashqml Breeze unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Here is the output after things have settled down. PID PPID COMMAND CONTEXT 767 1 /usr/bin/dbus-broker-launch system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 772 767 dbus-broker --log 4 --contr system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 3550 3509 /usr/bin/dbus-broker-launch unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3551 3550 dbus-broker --log 4 --contr unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 3687 3509 /usr/bin/gmenudbusmenuproxy unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
Troy, Thank you for your help with isolating the issue. After re-evaluating this issue, we agreed internally that the benefit of having selinuxuser_execmod boolean off by default prevails because of users of other desktop software or not using GUI at all. The problem is that all these applications run in the SELinux user context so the permission cannot be allowed for a particular process domain only like in some other cases (for another, execstack permission): SELinux boolean State Default Description boinc_execmem (on , on) Determine whether boinc can execmem/execstack. cups_execmem (off , off) Allow cups execmem/execstack httpd_execmem (off , off) Allow httpd scripts and modules execmem/execstack mplayer_execstack (off , off) Determine whether mplayer can make its stack executable. selinuxuser_execstack (on , on) Allow unconfined executables to make their stack executable. This should never, ever be necessary. Probably indicates a badly coded executable, but could indicate an attack. This executable should be reported in bugzilla that is the #c3 comment was not accurate. Switching the component to plasma-workspace to enable the boolean in its rpm postinst scriptlet, but not completely sure if this is the right component - it should be the parent of individual desktop subcomponents. Steps from the Independent Policy modules howto can be used: https://fedoraproject.org/wiki/SELinux/IndependentPolicy#Setting_Booleans_During_Installation Feel free to reach out to SELinux team in case of any questions.
I just want to make sure I understand what you are saying, and if I do understand, then I do have a question. We should set our own selinux policies for KDE during package installation. The most logical package would be during whatever provides plasmashell, which is plasma-workstation. If that is what you were saying, then I'll bring this before the KDE sig so we figure out the correct place to put it, as well as as the correct format. If that is what you are saying, then I'm very curious why we didn't hit this in Fedora?
(In reply to Troy Dawson from comment #18) > I just want to make sure I understand what you are saying, and if I do > understand, then I do have a question. > > We should set our own selinux policies for KDE during package installation. > The most logical package would be during whatever provides plasmashell, > which is plasma-workstation. > > If that is what you were saying, then I'll bring this before the KDE sig so > we figure out the correct place to put it, as well as as the correct format. I think you understand it right. Calling it "SELinux policies" is probably too high-sounding. There are already some packages which need to make some adjustments during install time. > If that is what you are saying, then I'm very curious why we didn't hit this > in Fedora? Because of the very late report. We wanted to make it happen before RHEL 9 GA, otherwise such a change surely would land in Fedora first and after a few months would get to RHEL. RHEL 8 remains unchanged. I see this was unfortunate coincidence.
(In reply to Zdenek Pytela from comment #19) > (In reply to Troy Dawson from comment #18) > > If that is what you are saying, then I'm very curious why we didn't hit this > > in Fedora? > > Because of the very late report. We wanted to make it happen before RHEL 9 > GA, otherwise such a change surely would land in Fedora first and after a > few months would get to RHEL. RHEL 8 remains unchanged. I see this was > unfortunate coincidence. OK, that's what I thought. So this change will hit Fedora at some point, and we (the kde-sig) should get Fedora's KDE packages ready, as well as EPEL's.
Is there a way we can define this so that when people build live media or appliance images with KDE software that the boolean is set properly? Because I can't find any guidance on how to do that.
*** Bug 2082887 has been marked as a duplicate of this bug. ***
Just realized the pull request for this was never merged, so the epel9-next updates didn't have this change. Fixing that now.
FEDORA-EPEL-NEXT-2022-9984d71297 has been submitted as an update to Fedora EPEL 9 Next. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-9984d71297
I have merged the pull request, so future updates will have the fix. I have also applied the fix to the epel9-next plasma-workspace, and built it. The bodhi update above has the fix.
FEDORA-EPEL-NEXT-2022-9984d71297 has been pushed to the Fedora EPEL 9 Next testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-NEXT-2022-9984d71297 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-NEXT-2022-9984d71297 has been pushed to the Fedora EPEL 9 Next stable repository. If problem still persists, please make note of it in this bug report.