Repeated security messages from SELinux

Ask Fedora
, ,
1

For the past few days, I’ve been experiencing issues with SELinux, first with Chrome, then with some mount points.
Log:

Jun 18 13:08:28 fedora bluetoothd[1081]: Failed to set mode: Failed (0x03)
Jun 18 13:09:25 fedora sddm-helper[1545]: gkr-pam: unable to locate daemon control file
Jun 18 13:09:28 fedora bluetoothd[1081]: Failed to set mode: Failed (0x03)
Jun 18 13:09:29 fedora bluetoothd[1081]: Failed to set mode: Failed (0x03)
Jun 18 13:09:32 fedora akonadiserver[2932]: org.kde.pim.akonadiserver: Cannot connect to agent instance with identifier 'akonadi_maildir_resource_0', error message: ''
Jun 18 13:14:35 fedora setroubleshoot[4917]: SELinux prevents systemd-fstab-g from getattr access on folder /var/lib/machines. For complete SELinux messages, run: sealert -l 75610a57-7c76-4a0c-bd56-c3381a59a8db
Jun 18 13:14:35 fedora setroubleshoot[4917]: failed to retrieve rpm info for path '/media/emanu/game':
Jun 18 13:14:37 fedora setroubleshoot[4917]: SELinux prevents systemd-fstab-g from getattr access on folder /media/emanu/game. For complete SELinux messages, run: sealert -l fd54b33a-65cd-43b5-9ad4-208ede172560 
jun 18 13:14:37 fedora setroubleshoot[4917]: failed to retrieve rpm info for path '/media/emanu/dati': 
Jun 18 13:14:39 fedora setroubleshoot[4917]: SELinux prevents systemd-fstab-g from getattr access on folder /media/emanu/dati. For complete SELinux messages, run: sealert -l fd54b33a-65cd-43b5-9ad4-208ede172560 
Jun 18 13:14:39 fedora setroubleshoot[4917]: failed to retrieve rpm info for path '/media/emanu/ssd': 
Jun 18 13:14:41 fedora setroubleshoot[4917]: SELinux prevents systemd-fstab-g from getattr access on folder /media/emanu/ssd. For complete SELinux messages, run: sealert -l fd54b33a-65cd-43b5-9ad4-208ede172560
Jun 18 16:01:32 fedora dbus-broker-launch[1077]: Activation request for 'org.bluez' failed.
Jun 18 16:01:32 fedora dbus-broker-launch[1077]: Activation request for 'org.bluez' failed.
Jun 18 16:01:33 fedora dbus-broker-launch[1077]: Activation request for 'org.freedesktop.nm_dispatcher' failed.

And the issues with Chrome and the Fedora user agent:
log:

Jun 18 20:04:52 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:52 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:52 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:52 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:52 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:53 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:53 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:53 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:53 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:53 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:04:54 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l 1c241c55-3660-4677-90d6-fc53389241ce
Jun 18 20:05:17 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l caa39702-a58e-4987-862b-13d1cbf7b69b
Jun 18 20:05:18 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l caa39702-a58e-4987-862b-13d1cbf7b69b
Jun 18 20:05:18 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l caa39702-a58e-4987-862b-13d1cbf7b69b

Jun 18 20:05:18 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process. For complete SELinux messages, run: sealert -l caa39702-a58e-4987-862b-13d1cbf7b69b
Jun 18 20:05:18 fedora sealert[4882]: gtk_grid_attach: assertion '_gtk_widget_get_parent (child) == NULL' failed
Jun 18 20:05:18 fedora sealert[4882]: gtk_grid_attach: assertion '_gtk_widget_get_parent (child) == NULL' failed
Jun 18 20:05:18 fedora setroubleshoot[4751]: SELinux prevents chrome from execheap access on a process.
⏎
⏎
***** Plugin allow_execheap (53.1 confidence) suggests ********************

vbnet

                                         If you do not think chrome should need to map the heap memory that is both writable and executable.
                                         Then you need to report a bug. This is potentially dangerous access.
                                         Contact your security administrator and report the issue.
                                         ⏎
                                         ⏎
                                         ***** Plugin catchall_boolean (42.6 confidence) suggests ******************
                                         
                                         If you want to allow selinuxuser to execheap
                                         Then you need to inform SELinux by enabling the boolean 'selinuxuser_execheap'.
                                         
                                         Run
                                         setsebool -P selinuxuser_execheap 1
                                         ⏎
                                         ⏎
                                         ***** Plugin catchall (5.76 confidence) suggests **************************
                                         
                                         If you believe chrome should be allowed execheap access to processes labeled unconfined_t by default.
                                         Then you should report the issue as a bug.
                                         You can generate a local policy module to allow this access.
                                         Run
                                         allow this access for now by executing:
                                         # ausearch -c 'chrome' --raw | audit2allow -M my-$MODULE_NAME
                                         # semodule -X 300 -i my-chrome.pp

Chrome is installed via Flatpak by Flathub. Previously I have never seen these Selinux messages.

emanu@fedora ~> flatpak info com.google.Chrome 

Google Chrome - The web browser from Google

          ID: com.google.Chrome
         Ref: app/com.google.Chrome/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 126.0.6478.61-1
     License: LicenseRef-proprietary
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 21,3 MB
     Runtime: org.freedesktop.Platform/x86_64/22.08
         Sdk: org.freedesktop.Sdk/x86_64/22.08

      Commit: 91aba6e2717d568dcc38d512cc3da31d31b1657aada6745dc9febed388923ccd
      Parent: 98df98d61d33b1ef51bfb283e76a9fbf0adee42ec2e45c6c771161edb7289cb3
     Subject: chrome: Update chrome.deb to 126.0.6478.61-1 (7b957488)
        Date: 2024-06-15 03:34:57 +0000

Already done, and nothing has changed: touch /.autorelabel; reboot

Edit: The partitions are mounted without issues, but I see those messages, is that normal?
As for Chrome, I had to reset the user configuration in “/home/user/.var/…”
Chrome seems to work fine after the reset.

1 Like
2

Can you please check in your journalctl when exactly these issues have begun?

Then, please check in the logs of dnf in /var/log/dnf* when the package selinux-policy-40.22-1.fc40 has been installed.

Please let us know the exact time of both.

I ask because I would like to know if these issues have been introduced by the recent update of the policies.

Also, another question: is it just the logs, or do they also cause issues?

3

Thank you for replying so quickly.
For the mount of the devices it is only a view of the registers, never seen before, but I can access.
As for Chrome, just ago I found, again, problems, with error in viewing any page. When it happens, I also get a notification of the USER AGENT FEDORA that crashes.
Restarted Chrome, and now it seems to be working again.
The logs:

giu 18 21:21:55 fedora com.google.Chrome.desktop[8635]: [848:484:0618/212155.989558:ERROR:v8_initializer.cc(809)] V8 process OOM (Failed to reserve virtual memory for CodeRange).
giu 18 21:21:55 fedora audit[9543]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=9543 comm="chrome" exe="/app/extra/chrome" sig=5 res=1
giu 18 21:21:55 fedora com.google.Chrome.desktop[8624]: [0618/212155.989802:ERROR:scoped_ptrace_attach.cc(27)] ptrace: Operation not permitted (1)
giu 18 21:21:55 fedora com.google.Chrome.desktop[8604]: [2:2:0618/212155.993692:ERROR:service_worker_task_queue.cc(244)] DidStartWorkerFail cfhdojbkjhnklbpkdaibdccddilifddb: 3
giu 18 21:21:57 fedora setroubleshoot[8854]: SELinux impedisce a chrome un accesso execheap su un processo. Per i messaggi SELinux completi, eseguire: sealert -l caa39702-a58e-4987-862b-13d1cbf7b69b
giu 18 21:21:57 fedora setroubleshoot[8854]: SELinux impedisce a chrome un accesso execheap su un processo.
                                             ⏎
                                             ⏎
                                             ***** Plugin allow_execheap(53.1 confidenza) suggerisce********************
                                             
                                             Se non pensi chrome dovrebbe avere bisogno di mappare la memoria heap che è sia scrivibile che eseguibile.
                                             Quindi è necessario riportare un bug. Questo è un accesso potenzialmente pericoloso.
                                             Fai
                                             contattare il proprio amministratore di sicurezza e riportare il problema.
                                             ⏎
                                             ⏎
                                             ***** Plugin catchall_boolean(42.6 confidenza) suggerisce******************
                                             
                                             Se lo desidera allow selinuxuser to execheap
                                             Quindi è necessario informare SELinux abilitando il booleano 'selinuxuser_execheap' .
                                             
                                             Fai
                                             setsebool -P selinuxuser_execheap 1
                                             ⏎
                                             ⏎
                                             ***** Plugin catchall(5.76 confidenza) suggerisce**************************
                                             
                                             Se ci credi chrome dovrebbe essere consentito execheap accesso ai processi etichettati unconfined_t per impostazione predefinita.
                                             Quindi si dovrebbe riportare il problema come bug.
                                             E' possibile generare un modulo di politica locale per consentire questo accesso.
                                             Fai
                                             consentire questo accesso per ora eseguendo:
                                             # ausearch -c 'chrome' --raw | audit2allow -M my-$MODULE_NOME
                                             # semodule -X 300 -i miei-chrome.pp

It seems that it has started from this point, I have no less recent logs, so I’m not sure::

-- Boot 7ed3bfde61e74737af79810a4f05dda4 --
giu 14 14:01:12 fedora kernel: LSM: initializing lsm=lockdown,capability,yama,selinux,bpf,landlock,integrity
giu 14 14:01:12 fedora kernel: SELinux:  Initializing.
giu 14 14:01:12 fedora kernel: evm: security.selinux
giu 14 14:01:12 fedora systemd[1]: systemd 255.7-1.fc40 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBF>
giu 14 14:01:20 fedora kernel: audit: type=1404 audit(1718366479.662:2): enforcing=1 old_enforcing=0 auid=4294967295 ses=4294967295 enabled=1 old-enabled=1 lsm=selinux res=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability network_peer_controls=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability open_perms=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability extended_socket_class=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability always_check_network=0
giu 14 14:01:20 fedora kernel: SELinux:  policy capability cgroup_seclabel=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability nnp_nosuid_transition=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability genfs_seclabel_symlinks=1
giu 14 14:01:20 fedora kernel: SELinux:  policy capability ioctl_skip_cloexec=0
giu 14 14:01:20 fedora kernel: SELinux:  policy capability userspace_initial_context=0
giu 14 14:01:20 fedora kernel: audit: type=1403 audit(1718366479.755:3): auid=4294967295 ses=4294967295 lsm=selinux res=1
giu 14 14:01:20 fedora systemd[1]: Successfully loaded SELinux policy in 93.635ms.
giu 14 14:01:20 fedora systemd[1]: systemd 255.7-1.fc40 running in system mode (+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD +LIBCRYPTSETUP +LIBF>
giu 14 14:01:21 fedora systemd[1]: selinux-autorelabel-mark.service - Mark the need to relabel after reboot was skipped because of an unmet condition check (ConditionSecurity=!selinux).
giu 14 14:01:21 fedora systemd[1]: selinux-autorelabel-mark.service - Mark the need to relabel after reboot was skipped because of an unmet condition check (ConditionSecurity=!selinux).
giu 14 14:01:21 fedora systemd[1]: selinux-autorelabel-mark.service - Mark the need to relabel after reboot was skipped because of an unmet condition check (ConditionSecurity=!selinux).
giu 14 14:01:24 fedora systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs...
giu 14 14:01:24 fedora systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs.
giu 14 14:01:25 fedora setroubleshoot[1373]: SELinux impedisce a systemd-fstab-g un accesso getattr su cartella /var/lib/machines. Per i messaggi SELinux completi, eseguire: sealert -l 8fa3145c-efa2-4d2b-b5af-ffeeb0362ede

The last History with the upgrade of Selinux:

ID transazione : 188
Ora inizio     : mer 12 giu 2024, 12:53:35
rpmdb iniziale : 8e02a8b77331778ce4e378aa304fde3197268c02f705ba2b677384cb1b890671
Ora termine    : mer 12 giu 2024, 12:54:21 (46 secondi)
rpmdb finale   : 3601cc9a5dec0b2119912dd2a15e1f9762cfbc6f92e801a39469f9a4b149b00a
Utente         : Super User <root>
Codice di uscita    : Completato
Rilascio: 
Linea di comando   : 
Commento        : 
Pacchetti modificati:
    Upgrade  autocorr-en-1:24.2.4.2-2.fc40.noarch                              @updates
    Upgrade  autocorr-it-1:24.2.4.2-2.fc40.noarch                              @updates
    Upgrade  bolt-0.9.8-2.fc40.x86_64                                          @updates
    Upgrade  cpp-14.1.1-5.fc40.x86_64                                          @updates
    Upgrade  gcc-14.1.1-5.fc40.x86_64                                          @updates
    Upgrade  gcc-c++-14.1.1-5.fc40.x86_64                                      @updates
    Upgrade  libstdc++-14.1.1-5.fc40.x86_64                                    @updates
    Upgrade  libstdc++-devel-14.1.1-5.fc40.x86_64                              @updates
    Upgrade  selinux-policy-40.22-1.fc40.noarch                                @updates
    Upgrade  selinux-policy-targeted-40.22-1.fc40.noarch                       @updates
    Upgraded autocorr-en-1:24.2.3.2-2.fc40.noarch                              @@System
    Upgraded autocorr-it-1:24.2.3.2-2.fc40.noarch                              @@System
    Upgraded bolt-0.9.7-1.fc40.x86_64                                          @@System
    Upgraded cpp-14.1.1-4.fc40.x86_64                                          @@System
    Upgraded fastfetch-2.14.0-1.fc40.x86_64                                    @@System
    Upgraded gcc-14.1.1-4.fc40.x86_64                                          @@System
    Upgraded gcc-c++-14.1.1-4.fc40.x86_64                                      @@System
    Upgraded golang-1.22.3-1.fc40.x86_64                                       @@System
    Upgraded golang-bin-1.22.3-1.fc40.x86_64                                   @@System
    Upgraded golang-src-1.22.3-1.fc40.noarch                                   @@System
    Upgraded libstdc++-14.1.1-4.fc40.x86_64                                    @@System
    Upgraded libstdc++-devel-14.1.1-4.fc40.x86_64                              @@System
    Upgraded selinux-policy-40.20-1.fc40.noarch                                @@System
    Upgraded selinux-policy-targeted-40.20-1.fc40.noarch                       @@System

The currently installed version:

sudo dnf info selinux-policy
[sudo] password di emanu: 
Ultima verifica della scadenza dei metadati: 1:29:27 fa il mar 18 giu 2024, 20:41:50.
Pacchetti installati
Name         : selinux-policy
Version      : 40.22
Rilascio     : 1.fc40
Architecture : noarch
Size         : 29 k
Sorgente     : selinux-policy-40.22-1.fc40.src.rpm
Repository   : @System
Dal repo     : updates
Summary      : SELinux policy configuration
URL          : https://github.com/fedora-selinux/selinux-policy
Licenza      : GPL-2.0-or-later
Description  : SELinux core policy package.
             : Originally based off of reference policy,
             : the policy has been adjusted to provide support for Fedora.
4

Have you maybe used a command that limits the output to one boot? The system should normally not delete logs so quickly. Also, if you provide output, please let us always know how this output was created, so the very command so that we have a context of the output. And make clear if you removed / cut something.

Can you give the output of the following:

sudo journalctl | grep setroubleshoot → I know, ugly, but works :wink: → shall just ensure that there is no availability of earlier log entries with regards to setroubleshoot in an inclusive way (I only trust the original grep conditionless :smiley: ).I’m wondering about the lack of older entries, but depending on the command you used above, it is not yet for sure if there are just no denials or no entries at all available. Feel free to remove everything before June.
sudo journalctl --list-boots → just to check if there are generally no older logs, but also to compare against the above and below commands. Again, feel free to remove everything before June. At this time, feel free to also remove the very times except the days of the boots if you consider that private, although more is always better.
cat /var/log/dnf.* | grep selinux-policy-40.22-1.fc40 → I would like to link exactly this one package to denials before and after its appearance in this file. Along with the other commands, this should be possible, at least in case logs of boots of the time are available.

sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today → do that after you provoked all issues already on the very day; good overview of related data
sudo journalctl --boot=0 -g avc:..denied → please create a dedicated boot for that: boot, then just provoke each of the issues/denials, note and let us know the very system time you provoked which issue/denial, and then create the output of that command

Don’t forget to put all in code blocks ^^

I guess that will lead to another bug report and will need an adjustment of selinux-policy, but I want to be sure explicitly first.

5

No

I cut some repetitive lines due to a character limit issue.
Unfortunately, I still exceed the character limit; I’ve placed everything on Pastebin.

emanu@fedora ~> sudo journalctl | grep setroubleshoot > selinux_grep

https://pastebin.com/KQ8mMUVz

It seems not, only June.
There are only my attempts to trace the installation of the package with “dnf history”.
Maybe, why do I update with “Plasma Discovery” (Packagekit)?

emanu@fedora ~> cat /var/log/dnf.* | grep selinux-policy-40.22-1.fc40

2024-06-18T21:56:10+0200 DDEBUG Command: dnf history list selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:10+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:10+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:16+0200 DDEBUG Command: dnf history selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:16+0200 DDEBUG Extra commands: ['history', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:16+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:23+0200 DDEBUG Command: dnf history info selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:23+0200 DDEBUG Extra commands: ['history', 'info', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:24+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.

This is the Journaling list:

emanu@fedora ~ [SIGINT]> sudo journalctl --list-boots
[sudo] password di emanu: 
IDX BOOT ID                          FIRST ENTRY                  LAST ENTRY                  
-37 7ed3bfde61e74737af79810a4f05dda4 Fri 2024-06-14 14:05:11 CEST Fri 2024-06-14 14:36:46 CEST
-36 6642ad04607647f5833dd7d7039ff39d Fri 2024-06-14 14:37:03 CEST Fri 2024-06-14 15:03:51 CEST
-35 e6f69e23e1bf43cab28796bdcf27f5e7 Fri 2024-06-14 20:39:11 CEST Fri 2024-06-14 22:19:55 CEST
-34 43b74d5dd5c34f31b0b20fc5d2c32e23 Fri 2024-06-14 22:20:13 CEST Fri 2024-06-14 23:57:25 CEST
-33 1010aa4c50e843ad9ccad3cd3aeccaa8 Sat 2024-06-15 00:45:00 CEST Sat 2024-06-15 01:09:05 CEST
-32 07affeb5175545e993cdf91c7d8e9470 Sat 2024-06-15 12:06:43 CEST Sat 2024-06-15 13:41:02 CEST
-31 9ca78a45a86e4704a57d388770eafa9e Sat 2024-06-15 13:41:20 CEST Sat 2024-06-15 13:41:43 CEST
-30 c5ef941f6bb74c3b8819fa061e7c84e3 Sat 2024-06-15 13:42:02 CEST Sat 2024-06-15 13:55:22 CEST
-29 8b83f386c71249918dd69b6422358942 Sat 2024-06-15 13:55:39 CEST Sat 2024-06-15 14:07:04 CEST
-28 5c49fc21ade5426e905ead360a4e1f97 Sat 2024-06-15 14:07:21 CEST Sat 2024-06-15 14:28:02 CEST
-27 2fd463620ef545e7b9c1b097ca3cb646 Sat 2024-06-15 14:28:19 CEST Sat 2024-06-15 14:36:47 CEST
-26 775cadfd85ac4917a5b189de0560ea89 Sat 2024-06-15 14:37:05 CEST Sat 2024-06-15 14:44:13 CEST
-25 ef35ad2eb8db4ee5ae9ea6360ee835e9 Sat 2024-06-15 14:44:30 CEST Sat 2024-06-15 14:49:45 CEST
-24 deb4601476a74020943cceab186c41a0 Sat 2024-06-15 17:31:35 CEST Sat 2024-06-15 17:54:43 CEST
-23 4edf2842aca54d1cb01891cd460cf69b Sat 2024-06-15 17:55:01 CEST Sat 2024-06-15 18:03:21 CEST
-22 27ea6ee68e684ab2ab38ed6b6034e365 Sat 2024-06-15 18:03:48 CEST Sat 2024-06-15 19:46:55 CEST
-21 26a4b786e92740679e407e87162dd7e6 Sat 2024-06-15 19:47:19 CEST Sat 2024-06-15 19:55:56 CEST
-20 352dfa7c46ef4183a69a28296aeb1eb0 Sat 2024-06-15 19:56:14 CEST Sat 2024-06-15 20:10:35 CEST
-19 835e250bb6ee4092b50646ad5058747d Sat 2024-06-15 20:10:52 CEST Sat 2024-06-15 21:17:57 CEST
-18 17b7572a6ea24aeb89ba58d44d636199 Sat 2024-06-15 21:18:14 CEST Sun 2024-06-16 00:04:37 CEST
-17 ee73763df8644ca5a6941c814b415529 Sun 2024-06-16 12:38:54 CEST Sun 2024-06-16 12:58:17 CEST
-16 1a0b5fc9d9be416bb59be7ef1fd52c50 Sun 2024-06-16 12:58:35 CEST Sun 2024-06-16 12:58:55 CEST
-15 5e31b3c95a3d4acf9e40e0fe4827e5ca Sun 2024-06-16 12:59:13 CEST Sun 2024-06-16 17:58:12 CEST
-14 aab86ebe73bf420aa87b6e5100fc234f Sun 2024-06-16 17:58:30 CEST Sun 2024-06-16 17:59:01 CEST
-13 2b0aab7a8c0e46e987d64cbdde4d1a67 Sun 2024-06-16 17:59:19 CEST Sun 2024-06-16 22:36:27 CEST
-12 04cf66b99a8f4ba2b646338555e954c3 Mon 2024-06-17 11:27:37 CEST Mon 2024-06-17 11:32:25 CEST
-11 38b15b1bffa94af5ad608028d1831d20 Mon 2024-06-17 11:32:43 CEST Mon 2024-06-17 11:34:19 CEST
-10 3f9345ce8bf449d3a9dd221bd47d8b73 Mon 2024-06-17 11:34:37 CEST Mon 2024-06-17 15:59:07 CEST
 -9 0baa694aa1ad4608b223e89e0a5453a8 Mon 2024-06-17 16:35:56 CEST Mon 2024-06-17 18:41:41 CEST
 -8 3a225b7cc710425ba620126f40c10d2e Mon 2024-06-17 18:41:59 CEST Mon 2024-06-17 18:46:39 CEST
 -7 ed41b9d6784d440795237267aa48eb65 Mon 2024-06-17 21:40:01 CEST Mon 2024-06-17 21:51:47 CEST
 -6 ae09c4f7deb746dbb09586f9a39c550c Mon 2024-06-17 21:52:05 CEST Mon 2024-06-17 22:00:27 CEST
 -5 501fd01a9cc140879818aa8bdd981d66 Mon 2024-06-17 22:00:54 CEST Mon 2024-06-17 22:10:34 CEST
 -4 cba12932576c43f88290149b284eb893 Mon 2024-06-17 22:10:58 CEST Tue 2024-06-18 00:05:46 CEST
 -3 eb320fb42cbe4d21ac263fa864a52e3f Tue 2024-06-18 13:08:17 CEST Tue 2024-06-18 16:01:33 CEST
 -2 964579fff0fc4dd3a1751ddb411549c7 Tue 2024-06-18 19:39:12 CEST Tue 2024-06-18 22:19:06 CEST
 -1 3a8dd71b339f459285e7cfbc5ef816ae Tue 2024-06-18 22:19:24 CEST Tue 2024-06-18 23:24:19 CEST
  0 569473a557da4e0391b3b6491658087a Tue 2024-06-18 23:24:37 CEST Tue 2024-06-18 23:54:00 CEST

I tried to check for each single boot, the problem of Selinux’s denial seems to start: “Jun 16 12:58:52 Fedora Audit [1309]”, then is frequent but not in all boot.
Here is the complete list:

https://pastebin.com/zbLZkXH7

If you need more information let me know. Thank you

6

Please use the command I gave you, so with sudo, just to be sure (usually this should not make a difference if the file mode bits are default, but I am currently cautious with your system). The point here is, it seems that your dnf log also does not contain logs of earlier days. It seems to not, or no longer, contain the installation of the very package.

I think the first question here is how your journalctl logs and your dnf logs were deleted if you haven’t done that manually or changed default configs (auto delete or so) but have the Fedora installed longer than June. Or did you anything that could be related to that? Do you have made any noteworthy changes on your system recently?

I maybe should have asked that earlier but I got a little distracted by the SELinux denials: which Fedora do you use? I’m quite sure its Fedora 40 KDE Spin, right? Just to consider everything…

You maybe also provide uname -r (just very generic information of your Fedora and its kernel). Can you also provide output of cat /proc/sys/kernel/tainted (that tells me if your kernel is tainted)?

AVC avc:  denied  { getattr } for  pid=4881 comm="systemd-fstab-g"

This is the type of denial that is currently under investigation. Quite sure the named package introduced it. We have currently an open ticket about it. → 2292191 – 40.22-1.fc40 breaks cryptsetup action on startup: related denial logged during boot since update to 40.22-1 -> related device no longer mounted on boot

Maybe your Chrome issue is linked to the same, but be aware that Chrome is not officially supported. However, I tend to focus the systemd issue first anyway.

Please provide that, too. At the best, also in a pastebin so that I can link it in bugzilla.

You might also create a full log of a dedicated boot. So, boot, login, open your Chrome, and shutdown. Then boot again and create immediately sudo journalctl --boot=-1 --no-hostname and create another pastebin. Feel free to anonymize things you consider private, e.g., MAC addresses or so.

Please also provide ls -l /boot/ | grep linu , just as a rough indication what the oldest kernel is.

Do you mean you update with Plasma Discovery? Maybe that’s an explanation for the dnf logs, not sure if that tool somehow avoids dnf logs since I don’t use it. But doesn’t explain the lack of journalctl logs.

Just a slight addition: --boot=0 seems to be the one that is missing :wink: The boots are then minus, not plus. So, e.g., --boot=-5 and not --boot=5. But one of a boot with the issue should be enough anyway :wink: So --boot=0 is the current one, and -1 is the last one.

I will have another look tomorrow when you provided all data, and I guess I will then add your case to the existing ticket I mentioned above. That one already tackles the issue around comm=“systemd-fstab-g” denials. I would add your data to maybe offer another perspective. Maybe your Chrome data gives also another perspective, maybe its related.

However, the other question in your case is the lack of logs. Maybe we find out tomorrow.

7

BTW, also on my system journalctl --list-boots yelds “only” 33 lines (from -32 to 0), so I don’t think that this is an issue.

8

Interesting. Thanks for letting me know. Not sure if maybe the defaults have changed at some release. It seems the choice is now made based upon the numbers of boot, not time. As most people boot once a day that could explain that this did not yet come up before. I’ll check later, but then we can focus on the other issue.

@emanuc just focus on providing:

Ensure that you have the issues contained on a very day, and provide the following:
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Create a “dedicated boot” as described above, then boot again and:
sudo journalctl --boot=-1 -g avc:..denied (ensure -1 , not 1 → -1 is the boot before the one you are currently working in)
→ If you have already a current boot with with boot=0 in pastebin and ensured all denials are contained, that should be fine too (I see you are already writing).

We do not need in this case the full sudo journalctl --boot=-1 --no-hostname and ls -l /boot/ | grep linu, at least for now.

If you can elaborate any chrome denial, it would be nice too. E.g., when there is a denial on 13:30:25, you might mention that at the second of this very denial (or at the very second X that was immediately before or after), you tried A and B happened or so. Just in case the chrome issue surpasses the fixing of the other bug.

With the assumption that your output will comply to the issue we know, I will add your data to the bug report. Then we have to give the maintainer some time to solve it. But he already works on that, as mentioned above.

9

The explanation might be that sometimes I use Plasma Discover ( PackageKit) and other times I update from the CLI with DNF
Using the “sudo” command, the result is the same:

emanu@fedora ~> sudo cat /var/log/dnf.* | grep selinux-policy-40.22-1.fc40
2024-06-18T21:56:10+0200 DDEBUG Command: dnf history list selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:10+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:10+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:16+0200 DDEBUG Command: dnf history selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:16+0200 DDEBUG Extra commands: ['history', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:16+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:23+0200 DDEBUG Command: dnf history info selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:23+0200 DDEBUG Extra commands: ['history', 'info', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:24+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.

I also tried without specifying the version:

emanu@fedora ~> sudo cat /var/log/dnf.* | grep selinux-policy
2024-03-27T20:28:06+0100 INFO Downloading: http://fedora.ipacct.com/fedora/linux/updates/testing/40/Everything/x86_64/Packages/s/selinux-policy-40.15-1.fc40.noarch.rpm
2024-03-27T20:28:06+0100 INFO Downloading: http://fedora.ipacct.com/fedora/linux/updates/testing/40/Everything/x86_64/Packages/s/selinux-policy-targeted-40.15-1.fc40.noarch.rpm
2024-06-18T21:36:36+0200 DDEBUG Command: dnf history selinux-policy.noarch 
2024-06-18T21:36:36+0200 DDEBUG Extra commands: ['history', 'selinux-policy.noarch']
2024-06-18T21:36:37+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy.noarch'.
2024-06-18T21:36:44+0200 DDEBUG Command: dnf info selinux-policy.noarch 
2024-06-18T21:36:44+0200 DDEBUG Extra commands: ['info', 'selinux-policy.noarch']
2024-06-18T21:45:48+0200 DDEBUG Command: dnf history redo selinux-policy 
2024-06-18T21:45:48+0200 DDEBUG Extra commands: ['history', 'redo', 'selinux-policy']
2024-06-18T21:46:06+0200 DDEBUG Command: dnf info selinux-policy 
2024-06-18T21:46:06+0200 DDEBUG Extra commands: ['info', 'selinux-policy']
2024-06-18T21:46:17+0200 DDEBUG Command: dnf history redo selinux-policy-40.22-1 
2024-06-18T21:46:17+0200 DDEBUG Extra commands: ['history', 'redo', 'selinux-policy-40.22-1']
2024-06-18T21:46:17+0200 CRITICAL Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1'.
ValueError: invalid literal for int() with base 10: 'selinux-policy-40.22-1'
2024-06-18T21:46:24+0200 DDEBUG Command: dnf history redo selinux-policy-40.22 
2024-06-18T21:46:24+0200 DDEBUG Extra commands: ['history', 'redo', 'selinux-policy-40.22']
2024-06-18T21:46:25+0200 CRITICAL Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22'.
ValueError: invalid literal for int() with base 10: 'selinux-policy-40.22'
2024-06-18T21:46:28+0200 DDEBUG Command: dnf history redo selinux-policy-* 
2024-06-18T21:46:28+0200 DDEBUG Extra commands: ['history', 'redo', 'selinux-policy-*']
2024-06-18T21:46:29+0200 CRITICAL Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-*'.
ValueError: invalid literal for int() with base 10: 'selinux-policy-*'
2024-06-18T21:46:31+0200 DDEBUG Command: dnf history redo selinux-policy 
2024-06-18T21:46:31+0200 DDEBUG Extra commands: ['history', 'redo', 'selinux-policy']
2024-06-18T21:46:43+0200 DDEBUG Command: dnf history rollback selinux-policy-40.22-1 
2024-06-18T21:46:43+0200 DDEBUG Extra commands: ['history', 'rollback', 'selinux-policy-40.22-1']
2024-06-18T21:46:43+0200 CRITICAL Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1'.
ValueError: invalid literal for int() with base 10: 'selinux-policy-40.22-1'
2024-06-18T21:46:46+0200 DDEBUG Command: dnf history rollback selinux-policy 
2024-06-18T21:46:46+0200 DDEBUG Extra commands: ['history', 'rollback', 'selinux-policy']
2024-06-18T21:46:57+0200 DDEBUG Command: dnf history userinstalled selinux-policy-40.22-1 
2024-06-18T21:46:57+0200 DDEBUG Extra commands: ['history', 'userinstalled', 'selinux-policy-40.22-1']
2024-06-18T21:46:57+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1'.
2024-06-18T21:47:16+0200 DDEBUG Command: dnf history list selinux-policy 
2024-06-18T21:47:16+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy']
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.18-2.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.18-2.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.18-2.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.18-2.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
2024-06-18T21:48:54+0200 DDEBUG Command: dnf history list selinux-policy 
2024-06-18T21:48:54+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy']
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-40.20-1.fc40.noarch".
  Cannot find rpm nevra "selinux-policy-targeted-40.20-1.fc40.noarch".
2024-06-18T21:53:10+0200 DDEBUG Command: dnf history list selinux-policy 
2024-06-18T21:53:10+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy']
2024-06-18T21:54:53+0200 DDEBUG Command: dnf history list selinux-policy 
2024-06-18T21:54:53+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy']
2024-06-18T21:56:10+0200 DDEBUG Command: dnf history list selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:10+0200 DDEBUG Extra commands: ['history', 'list', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:10+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:16+0200 DDEBUG Command: dnf history selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:16+0200 DDEBUG Extra commands: ['history', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:16+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T21:56:23+0200 DDEBUG Command: dnf history info selinux-policy-40.22-1.fc40.noarch 
2024-06-18T21:56:23+0200 DDEBUG Extra commands: ['history', 'info', 'selinux-policy-40.22-1.fc40.noarch']
2024-06-18T21:56:24+0200 INFO Non è stata trovata alcuna operazione che manipola il pacchetto 'selinux-policy-40.22-1.fc40.noarch'.
2024-06-18T22:11:17+0200 DDEBUG Command: dnf info selinux-policy 
2024-06-18T22:11:17+0200 DDEBUG Extra commands: ['info', 'selinux-policy']
2024-03-27T20:25:52+0100 DEBUG ---> Il pacchetto selinux-policy.noarch 40.13-1.fc40 sarà aggiornato
2024-03-27T20:25:52+0100 DEBUG ---> Il pacchetto selinux-policy.noarch 40.15-1.fc40 sarà un aggiornamento
2024-03-27T20:25:52+0100 DEBUG ---> Il pacchetto selinux-policy-targeted.noarch 40.13-1.fc40 sarà aggiornato
2024-03-27T20:25:52+0100 DEBUG ---> Il pacchetto selinux-policy-targeted.noarch 40.15-1.fc40 sarà un aggiornamento
 selinux-policy                                                                 noarch                                  40.15-1.fc40                                               updates-testing                                         53 k
 selinux-policy-targeted                                                        noarch                                  40.15-1.fc40                                               updates-testing                                        6.9 M
2024-03-27T20:30:20+0100 DEBUG ---> Il pacchetto selinux-policy.noarch 40.13-1.fc40 sarà aggiornato
2024-03-27T20:30:20+0100 DEBUG ---> Il pacchetto selinux-policy.noarch 40.15-1.fc40 sarà un aggiornamento
2024-03-27T20:30:20+0100 DEBUG ---> Il pacchetto selinux-policy-targeted.noarch 40.13-1.fc40 sarà aggiornato
2024-03-27T20:30:20+0100 DEBUG ---> Il pacchetto selinux-policy-targeted.noarch 40.15-1.fc40 sarà un aggiornamento
 selinux-policy                                  noarch  40.15-1.fc40            updates-testing         53 k
 selinux-policy-targeted                         noarch  40.15-1.fc40            updates-testing        6.9 M
2024-03-27T20:33:09+0100 DEBUG Aggiornati: selinux-policy-40.15-1.fc40.noarch
2024-03-27T20:33:09+0100 DEBUG Aggiornati: selinux-policy-targeted-40.15-1.fc40.noarch
2024-03-27T20:31:19+0100 SUBDEBUG Upgrade: selinux-policy-40.15-1.fc40.noarch
2024-03-27T20:31:26+0100 SUBDEBUG Upgrade: selinux-policy-targeted-40.15-1.fc40.noarch
2024-03-27T20:32:13+0100 SUBDEBUG Upgraded: selinux-policy-40.13-1.fc40.noarch
2024-03-27T20:32:22+0100 SUBDEBUG Upgraded: selinux-policy-targeted-40.13-1.fc40.noarch


emanu@fedora ~> uname -r
6.9.4-200.fc40.x86_64

emanu@fedora ~> sudo cat /proc/sys/kernel/tainted
0

https://pastebin.com/FV2bJVG0

I use Fedora Spin KDE. No special modifications to the system, apart from changing the subvolumes (which I have always done since Fedora 33) and a udev rule to add “bg_reclaim_threshold”.
I am providing the UDEV rule configuration and the script:

emanu@fedora ~> cat /etc/udev/rules.d/99-btrfs-bg-data.rules
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_FS_TYPE}=="btrfs", RUN+="/usr/local/bin/btrfs--data-bg.sh %E{ID_FS_UUID}"

emanu@fedora ~> cat  /usr/local/bin/btrfs--data-bg.sh 
#!/bin/bash

sleep 30
echo 30 > /sys/fs/btrfs/$1/allocation/data/bg_reclaim_threshold

emanu@fedora ~> cat /sys/fs/btrfs/f265041b-2c7c-4135-b0c9-ab424428b3d1/allocation/data/bg_reclaim_threshold
0

If you need anything else, let me know. I hope I did everything correctly, if not, please let me know.

10

Yeah, let’s forget about this for now. We focus on the denials.

The first boot with the denials is:

-16 1a0b5fc9d9be416bb59be7ef1fd52c50 Sun 2024-06-16 12:58:35 CEST Sun 2024-06-16 12:58:55 CEST

Do you know why this boot has only 20 seconds of logs? Do you sometimes reboot after updates or so? Maybe does Plasma Discover forces you to reboot? Or does Plasma Discover install updates on boot?

Additionally, is it possible that you did not use Chrome between “giu 16 17:59:29” and “giu 17 21:45:44” ? I try to explain that Chrome denials start on the subsequent day. Maybe you do your discover updates at the end of your “daily use of your Fedora” or so?

My current assumption is that you introduced the selinux-policy on the 16th through discover, and that discover does not create dnf logs.

The first related logs are from 16th (boot=+22 equal boot=-16 in your case , please ensure to use “-” in future as I otherwise need much more time to read the output):

emanu@fedora ~ [1]> sudo journalctl --boot=22 -g avc:..denied
giu 16 12:58:52 fedora audit[1309]: AVC avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/var/lib/machines" dev="nvme0n1p2" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:>
giu 16 12:58:52 fedora kernel: audit: type=1400 audit(1718535532.832:72): avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/var/lib/machines" dev="nvme0n1p2" ino=256 scontext=system_u:system_r:systemd_fstab_generato>
giu 16 12:58:52 fedora kernel: audit: type=1400 audit(1718535532.832:73): avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/media/emanu/game" dev="sdc" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s0>
giu 16 12:58:52 fedora kernel: audit: type=1400 audit(1718535532.833:74): avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/media/emanu/dati" dev="sdb1" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s>
giu 16 12:58:52 fedora audit[1309]: AVC avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/media/emanu/game" dev="sdc" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlabe>
giu 16 12:58:52 fedora audit[1309]: AVC avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/media/emanu/dati" dev="sdb1" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlab>
giu 16 12:58:52 fedora audit[1309]: AVC avc:  denied  { getattr } for  pid=1309 comm="systemd-fstab-g" path="/media/emanu/ssd" dev="sda" ino=256 scontext=system_u:system_r:systemd_fstab_generator_t:s0 tcontext=system_u:object_r:unlabel>

You still didn’t provide ausearch outputs.

Please provide the ausearch that covers the “first appearances” since I also need an ausearch that can be linked to an available avc:…denied journalctl for comprehensible comparison, but also a current one.

This means the output of all three following commands (please use the exact commands as I provide them, just add “> file” if you want):
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err --start 06/16/2024 --end 06/18/2024
and then, please also start and use Chrome before doing the next command, in order to ensure the current logs of today cover both Chrome and the other issue (to know if it is still there and if it still looks the same:
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
At the best, you then also provide immediately after the ausearch of today, the journal of the running boot (no reboot in between) to compare against the current ausearch:
sudo journalctl --boot=0 -g avc:..denied (please stick with the 0)

→ ausearch is the major output for the bug report. The maintainer needs something that is focused on the major information and that has a common format to compare different users’ outputs.

11

In case you work by email, please read my last comment here in discourse and not in the email, since the email is likely to have cut the last paragraph

→ so please provide what is requested here: Repeated security messages from SELinux - #10 by py0xc3 (not what is written in the email you received)

12

Exactly. I restart after the upgrades because I use offline updates, both with Plasma Discover and from the CLI with DNF:

sudo dnf offline-upgrade download
sudo dnf offline-upgrade reboot

No, I use it at every startup, daily.

That’s my hypothesis as well. Plasma Discover uses PackageKit, just like GNOME Software.

I adapted it to my date format. Here are the logs on Pastebin:
sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err --start 16/06/2024 --end 18/06/2024
https://pastebin.com/cE1WLcjv

sudo ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

https://pastebin.com/KbMce20q

emanu@fedora ~> sudo journalctl --boot=0 -g avc:..denied
giu 19 20:34:00 fedora sudo[8546]:    emanu : TTY=pts/1 ; PWD=/home/emanu ; USER=root ; COMMAND=/usr/bin/journalctl --boot=0 -g avc:..denied

The problem is not always reproducible; for example, in this boot, everything is working fine so far. If you need anything else, let me know, and I’ll be happy to help.

13

I don’t know if it will be helpful, but I am also providing my subvolume and fstab configuration for the various mounts:

emanu@fedora ~> sudo btrfs subvol list -t /
ID      gen     top level       path
--      ---     ---------       ----
267     237656  5               var_lib_flatpak
666     237732  5               @home
670     237732  666             @home/emanu/.var
969     237635  5               var_lib_libvirt
970     237703  5               var_tmp
971     237730  5               var_log
972     237720  5               var_cache
973     237635  5               var_lib_machines
974     210251  5               opt
975     237720  5               @
1241    210251  5               @_developers
1259    237666  975             .snapshots
1287    221571  1259            .snapshots/25/snapshot
1343    228171  1259            .snapshots/55/snapshot
1371    233121  1259            .snapshots/74/snapshot
1377    234195  1259            .snapshots/80/snapshot
1388    235467  1259            .snapshots/81/snapshot
1390    236470  1259            .snapshots/83/snapshot
1398    237329  1259            .snapshots/84/snapshot
1400    237642  1259            .snapshots/86/snapshot


emanu@fedora ~> cat /etc/fstab

#
# /etc/fstab
# Created by anaconda on Wed Mar 27 15:01:58 2024
#
# Accessible filesystems, by reference, are maintained under '/dev/disk/'.
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info.
#
# After editing this file, run 'systemctl daemon-reload' to update systemd
# units generated from this file.
#
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /                       btrfs   noatime,compress=zstd:1,subvol=@ 0 0
UUID=C5A0-7101          /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /home                   btrfs   noatime,compress=zstd:1,subvol=@home    0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /opt                    btrfs   noatime,compress=zstd:1,subvol=opt 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/cache              btrfs   noatime,compress=zstd:1,subvol=var_cache 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/lib/flatpak        btrfs   noatime,compress=zstd:1,subvol=var_lib_flatpak 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/lib/libvirt        btrfs   noatime,compress=zstd:1,subvol=var_lib_libvirt 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/lib/machines       btrfs   noatime,compress=zstd:1,subvol=var_lib_machines 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/log                btrfs   noatime,compress=zstd:1,subvol=var_log 0 0
UUID=9c1c4ece-ece6-4c69-8b21-ea85865d2abf /var/tmp                btrfs   noatime,compress=zstd:1,subvol=var_tmp 0 0

# Mount vari dischi
LABEL=backup /media/emanu/backup btrfs compress-force=zstd:10,autodefrag,nofail,noauto 0 0
UUID=f265041b-2c7c-4135-b0c9-ab424428b3d1 /media/emanu/game/ btrfs noatime,nofail,autodefrag,compress-force=zstd:1,subvol=@game 0 0
UUID=2c3cd9ff-2940-4388-96af-daa0a3410ada /media/emanu/dati/ btrfs noatime,nofail,autodefrag,compress-force=zstd:3,subvol=@dati 0 0
LABEL=backup2T /media/emanu/backup2T btrfs noatime,space_cache=v2,compress-force=zstd:10,autodefrag,nofail,noauto 0 0
# Disco SSD per le VM
UUID=95d14f9d-8717-4ea0-8a79-34603a7269fe /media/emanu/ssd/ btrfs noatime,nofail,autodefrag,compress-force=zstd:1 0 0
14

Then provide journalctl -g avc:..denied --since "2024-06-18 00:01:00" so that we can set it in context to the ausearch

15

journalctl -g avc:..denied --since "2024-06-18 00:01:00"
https://pastebin.com/rzALWMgk

1 Like
16

This old bug report is interesting (even tough it doesn’t provide any solution): 2254434 – SELinux is preventing chrome from using the 'execheap' accesses on a process.

1 Like
17

I’m currently preparing to add data from here to the existing report about this “comm=systemd-fstab-g” denial. It is likely the same origin. And hopefully solved with the upcoming selinux policy update. Hopefully, the chrome one will be solved with that too.

18

Mh, @py0xc3 instead of the updated selinux package, could it be related to the 6.9 kernel?
If you follow some links in the aforementioned bug, you can find in other bug reports [1] [2] that the suspected was the kernel and subsequent updates solved the selinux execheap issue.

  1. https://bugzilla.redhat.com/show_bug.cgi?id=2254434 ↩︎

  2. https://bugzilla.redhat.com/show_bug.cgi?id=2252391#c16 ↩︎

1 Like
19

Well, for now this is in processing at the selinux-policy component. At least for the systemd-fstab-g denials, I can say for sure that I introduced them with selinux-policy.noarch 40.22-1.fc40, while the kernel itself did not change when the denial started to occur (including its impact). So for now, my guess is it is not the kernel. But let’s see how the ticket develops :wink:

Hopefully, the execheap will be solved along with the systemd-fstab-g, as they started to appear at the same time. I already added the logs of this user (which includes execheap denials of chrome) to the bug report.

1 Like
20

We have a new policy. It is currently in testing, but several people already tested it and since it is just a policy correction, you might already try it if you want. You can install it already at this time with the following command:
sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-2bc43119f3

Feel free to add Karma in bodhi if it works for you:
https://bodhi.fedoraproject.org/updates/FEDORA-2024-2bc43119f3

1 Like