Bug 2058657

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.