SELinux-error after update

[susejunky]

This morning I received a rather large update (> 1.800 packets) for my openSUSE Tumbleweed system

Operating System: openSUSE Tumbleweed 20260302
KDE Plasma Version: 6.6.1
KDE Frameworks Version: 6.23.0
Qt Version: 6.10.2
Kernel Version: 6.19.5-1-default (64-bit)
Graphics Platform: Wayland
Graphics Processor: Intel® Iris® Xe Graphics

I restarted the system after the update had completed and checked the logs to find this

# ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot
----
time->Wed Mar  4 10:20:19 2026
type=USER_AVC msg=audit(1772616019.377:107): pid=1063 uid=498 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-broker" sauid=498 hostname=? addr=? terminal=?'
#

audit2why told me

# ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot | audit2why
type=USER_AVC msg=audit(1772616019.377:107): pid=1063 uid=498 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-broker" sauid=498 hostname=? addr=? terminal=?'

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.
#

so I did

ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot | audit2allow -M rtkit_daemon

and

semodule -i rtkit_daemon.pp

touch /.autorelabel && systemctl isolate reboot

only to find a lot more errors

# LANG=C ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot
----
time->Wed Mar  4 10:48:47 2026
type=AVC msg=audit(1772617727.531:97): avc:  denied  { write } for  pid=1972 comm="rtkit-daemon" path="/run/systemd/inhibit/4.ref" dev="tmpfs" ino=5486 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:47 2026
type=AVC msg=audit(1772617727.583:105): avc:  denied  { write } for  pid=1981 comm="rtkit-daemon" path="/run/systemd/inhibit/5.ref" dev="tmpfs" ino=5502 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:47 2026
type=AVC msg=audit(1772617727.638:111): avc:  denied  { write } for  pid=1992 comm="rtkit-daemon" path="/run/systemd/inhibit/6.ref" dev="tmpfs" ino=5511 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:47 2026
type=AVC msg=audit(1772617727.701:116): avc:  denied  { write } for  pid=2000 comm="rtkit-daemon" path="/run/systemd/inhibit/7.ref" dev="tmpfs" ino=5520 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:47 2026
type=AVC msg=audit(1772617727.970:121): avc:  denied  { write } for  pid=2040 comm="rtkit-daemon" path="/run/systemd/inhibit/8.ref" dev="tmpfs" ino=5545 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:50 2026
type=AVC msg=audit(1772617730.378:126): avc:  denied  { write } for  pid=2178 comm="rtkit-daemon" path="/run/systemd/inhibit/10.ref" dev="tmpfs" ino=5592 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:50 2026
type=AVC msg=audit(1772617730.459:132): avc:  denied  { write } for  pid=2183 comm="rtkit-daemon" path="/run/systemd/inhibit/11.ref" dev="tmpfs" ino=5601 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:50 2026
type=AVC msg=audit(1772617730.532:137): avc:  denied  { write } for  pid=2191 comm="rtkit-daemon" path="/run/systemd/inhibit/12.ref" dev="tmpfs" ino=5610 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:50 2026
type=AVC msg=audit(1772617730.606:141): avc:  denied  { write } for  pid=2195 comm="rtkit-daemon" path="/run/systemd/inhibit/13.ref" dev="tmpfs" ino=5619 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:51 2026
type=AVC msg=audit(1772617731.591:150): avc:  denied  { write } for  pid=2325 comm="rtkit-daemon" path="/run/systemd/inhibit/14.ref" dev="tmpfs" ino=5654 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:51 2026
type=AVC msg=audit(1772617731.761:155): avc:  denied  { write } for  pid=2347 comm="rtkit-daemon" path="/run/systemd/inhibit/15.ref" dev="tmpfs" ino=5663 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
----
time->Wed Mar  4 10:48:51 2026
type=AVC msg=audit(1772617731.889:160): avc:  denied  { write } for  pid=2366 comm="rtkit-daemon" path="/run/systemd/inhibit/16.ref" dev="tmpfs" ino=5672 scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:object_r:systemd_logind_inhibit_var_run_t:s0 tclass=fifo_file permissive=0
#

In order not to mess up my system completely I removed rtkit_daemon.pp using system-config-selinux.

Now I do not know how to proceed. Any help would be appreciated.

Thank you.

[dcurtisfra]

@susejunky:

My personal recipe for dealing with SELinux – especially after Tumbleweed distribution upgrades with Packman and other non-Factory repositories enabled and active:

 # restorecon -F -R -v /usr
 # restorecon -F -R -v /tmp
 # restorecon -F -R -v /etc
 # restorecon -F -R -v /boot
 # restorecon -F -R -v /var
 # restorecon -F -R -v /root
 # restorecon -F -v /home
 # restorecon -F -R -v /home/«individual user (possibly Group) directories»

Also, if KDE then, clean out ‘~sddm/.cache/’ …

---

For real systems, various opinions have indicated that, using “restorecon -F -R -v /” isn’t a good idea – Terabytes of user (database) files will result in the system being “quiet” until the “restorecon” completes it’s tasks …

[susejunky]

Thank you for looking into my problem.

@dcurtisfra

My personal recipe for dealing with SELinux – especially after Tumbleweed distribution upgrades with Packman and other non-Factory repositories enabled and active:

 # restorecon -F -R -v /usr
 # restorecon -F -R -v /tmp
 # restorecon -F -R -v /etc
 # restorecon -F -R -v /boot
 # restorecon -F -R -v /var
 # restorecon -F -R -v /root
 # restorecon -F -v /home
 # restorecon -F -R -v /home/«individual user (possibly Group) directories»

Also, if KDE then, clean out ‘~sddm/.cache/’ …

Should I do this instead of creating rtkit_daemon.pp or after creating and installing rtkit_daemon.pp?

By the way: My system does not have a ~/sddm/.cache-directory nor is there a ~/.cache/sddm-directory.

[hcvv]

@susejunky

By the way: My system does not have a ~/sddm/.cache-directory nor is there a ~/.cache/sddm-directory.

But he says

@dcurtisfra

clean out ‘~sddm/.cache/’

boven:~ # ls  -l  ~sddm/.cache/
/var/lib/sddm/.cache/:
total 26988
drwxr-xr-x   2 sddm sddm     4096 Aug 29  2023 fontconfig
-rw-r--r--   1 sddm sddm 10547304 Jun 10  2022 icon-cache.kcache
drwxr-xr-x 159 sddm sddm     4096 Nov 18 21:45 mesa_shader_cache
-rw-------   1 sddm sddm    17732 Dec  8  2021 plasma-svgelements-openSUSE_v0.5
-rw-r--r--   1 sddm sddm 16875624 Jun 10  2022 plasma_theme_openSUSE_v0.5.kcache
-rw-r--r--   1 sddm sddm   165196 Jun 10  2022 qt_compose_cache_little_endian_7331925c60b6c16770f64cba585a6c84
drwxr-xr-x   2 sddm sddm     4096 Nov 18 21:45 qtshadercache-x86_64-little_endian-lp64
drwxr-xr-x   3 sddm sddm     4096 May 30  2018 sddm-greeter
boven:~ #

Because ~sddm is the home directory of user sddm:

boven:~ # grep sddm /etc/passwd
sddm:x:483:481:SDDM daemon:/var/lib/sddm:/bin/false
boven:~ #

(this is no comment on the value of cleaning it out or not, just to avoid confusion).

[susejunky]

@hcvv

But he says

@dcurtisfra

clean out ‘~sddm/.cache/’

Sorry, my fault. I did nor read carefully.

Thank you for pointing this out to me.

However clearing that directory did not make the error go away.

[malcolmlewis]

@susejunky It’s just a message, not an SELinux error as in “SELinux denies a common workload”…

What does ausearch -m avc -ts today | audit2allow show?

Ref: https://en.opensuse.org/Portal:SELinux#Common_pitfalls

[dcurtisfra]

@susejunky

Should I do this instead of creating rtkit_daemon.pp or after creating and installing rtkit_daemon.pp?

“restorecon” restores the default SELinux security contexts.
The <openSUSE SELinux Portal> states:

The openSUSE SELinux policy uses the Fedora SELinux policy as upstream with some openSUSE-specific changes. That means, most documentation for Fedora is also applicable to openSUSE.

• My view is that, the simplest solution is simply to trust the default openSUSE SELinux Policy.

Please be aware that, if, you’re only using the openSUSE Factory repositories, with no additional repositories at all, anywhere – then, theoretically, it shouldn’t be necessary to use “restorecon” – the openSUSE Factory places the correct SELinux security contexts on all the files in the system packages.

---

@susejunky

By the way: My system does not have a ~/sddm/.cache-directory nor is there a ~/.cache/sddm-directory.

Therefore, you’re not using KDE Plasma with SDDM as your Desktop Display Manager.

• My apologies – that wasn’t clear from your originating post.

[mhurron]

@dcurtisfra

My view is that, the simplest solution is simply to trust the default openSUSE SELinux Policy.

What, and do nothing? The default policy is not absolutely exhaustive and there are plenty of software interactions that are either not covered in it or were introduced by a version upgrade after the policy for that type was written.

You have 2 choices in this case, and what you do depends on your level of understanding (or desire to learn)

1. work with audit2allow, audit2why and a lot of research to understand the problem and maybe create a local policy to apply
2. open a bug report so others can look at it and determine if the issue is the policy or if the software is really doing something it shouldn’t https://en.opensuse.org/openSUSE:Submitting_bug_reports

Mod edit for openSUSE Bug reporting.

[susejunky]

@malcolmlewis

What does ausearch -m avc -ts today | audit2allow show?

Here we go:

# ausearch -m avc -ts today | audit2allow


#============= rtkit_daemon_t ==============
allow rtkit_daemon_t systemd_logind_inhibit_var_run_t:fifo_file write;

#============= systemd_rfkill_t ==============
allow systemd_rfkill_t self:capability { dac_override dac_read_search };
#

[malcolmlewis]

@susejunky So it’s a bug on your system, or the policy change you created has introduced…

I see the same alert (not an error) in your first command, but no matches on the second command…

ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot
----
time->Wed Mar  4 12:45:26 2026
type=USER_AVC msg=audit(1772649926.252:74): pid=820 uid=496 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for  scontext=system_u:system_r:rtkit_daemon_t:s0 tcontext=system_u:system_r:systemd_logind_t:s0 tclass=dbus permissive=0 exe="/usr/bin/dbus-broker" sauid=496 hostname=? addr=? terminal=?'

ausearch -m avc -ts today | audit2allow
<no matches>
Nothing to do

[susejunky]

@dcurtisfra

“restorecon” restores the default SELinux security contexts.

I ran restorecon -F -R -v / but the error message persists.

@dcurtisfra

Therefore, you’re not using KDE Plasma with SDDM as your Desktop Display Manager.

Please have a look at my post #1: I use plasma6 + sddm.

[malcolmlewis]

@susejunky if you run journalctl -t setroubleshoot does it produce output?

[susejunky]

@malcolmlewis

So it’s a bug on your system, …

How can I investigate the root cause any further?

@malcolmlewis

… or the policy change you created has introduced…

I removed that change ( rtkit_daemon.pp) as it brought only more errors (see my post #1).

[susejunky]

@malcolmlewis

if you run journalctl -t setroubleshoot does it produce output?

# journalctl -t setroubleshoot
-- No entries --
#

[malcolmlewis]

Is setroubleshoot-server installed?

I cannot replicate your issue with the three systems I have running Tumbleweed and SELinux, It’s not an error for a bug report (as indicated in the Portal link).

I suspect that output is showing those entries created are still present… Maybe a touch /.autorelabel and reboot will suffice.

[susejunky]

@malcolmlewis

Is setroubleshoot-server installed?

# LANG=C zypper se setroubleshoot
Loading repository data...
Reading installed packages...

S  | Name                        | Summary                                         | Type
---+-----------------------------+-------------------------------------------------+--------
   | setroubleshoot              | Helps troubleshoot SELinux problems             | package
   | setroubleshoot-doc          | Setroubleshoot documentation                    | package
i  | setroubleshoot-plugins      | Helps troubleshoot SELinux problems             | package
   | setroubleshoot-plugins-lang | Translations for package setroubleshoot-plugins | package
i  | setroubleshoot-server       | SELinux troubleshoot server                     | package
#

In the meantime I did

restorecon -F -R -v /

followed by

touch /.autorelabel && systemctl isolate reboot

but the message still is

# ausearch -m avc -ts today | audit2allow


#============= rtkit_daemon_t ==============
allow rtkit_daemon_t systemd_logind_inhibit_var_run_t:fifo_file write;

#============= systemd_rfkill_t ==============
allow systemd_rfkill_t self:capability { dac_override dac_read_search };
#

[malcolmlewis]

So the “today” output shows no errors, just the policies you created, setroubleshoot output shows no errors. All is OK with your system from an SELinux point of view.

So the only thing to work out is removing those two policies and normality will return…

[susejunky]

@malcolmlewis

just the policies you created

Sorry, but I do not quite understand:

@susejunky

so I did

ausearch -m avc,user_avc,selinux_err,user_selinux_err -ts boot | audit2allow -M rtkit_daemon

and

semodule -i rtkit_daemon.pp

touch /.autorelabel && systemctl isolate reboot

only to find a lot more errors

…

In order not to mess up my system completely I removed rtkit_daemon.pp using system-config-selinux.

So there should not be any policy introduced by me.

And what should I remove to get rid of those messages.

[malcolmlewis]

@susejunky If you read the information provided in the Portal link, only “avc” type are policy errors, those are the only ones that bug reports are for, you have a “user_avc” warning, which AFAIK is benign in nature.

If there is no output from these two commands ausearch -m avc -ts today | audit2allow and journalctl -t setroubleshoot there is nothing to worry about.

The command your running is for troubleshooting
You have created two policies;

#============= rtkit_daemon_t ==============
allow rtkit_daemon_t systemd_logind_inhibit_var_run_t:fifo_file write;

#============= systemd_rfkill_t ==============
allow systemd_rfkill_t self:capability { dac_override dac_read_search };

Which still seem to be present, which were introduced by you after running semodule -i rtkit_daemon.pp, does that help to clarify?

See https://en.opensuse.org/Portal:SELinux/Troubleshooting#audit2allow especially Danger zone! which as explained can lead to these types of additional problems and should not be used…

The fix, I have no idea unfortunately… It’s buried in there somewhere, I suggest starting from here https://en.opensuse.org/Portal:SELinux/Troubleshooting#Check_audit_log

[susejunky]

@malcolmlewis

You have created two policies;

#============= rtkit_daemon_t ==============
allow rtkit_daemon_t systemd_logind_inhibit_var_run_t:fifo_file write;

#============= systemd_rfkill_t ==============
allow systemd_rfkill_t self:capability { dac_override dac_read_search };

Which still seem to be present, which were introduced by you after running semodule -i rtkit_daemon.pp, does that help to clarify?

This is the file I installed with semodule -i

# cat rtkit_daemon.te

module rtkit_daemon 1.0;

require {
        type systemd_logind_t;
        type rtkit_daemon_t;
        class dbus send_msg;
}

#============= rtkit_daemon_t ==============
allow rtkit_daemon_t systemd_logind_t:dbus send_msg;
#

I can only see one (not two) policy in this file and it does not even fit any of the two policies mentioned above.