Created attachment 2057094 [details]
File: description

Created attachment 2057095 [details]
File: os_info

SSHing into my other machine which is not affected I don't see a /var/lib/sss/pipes/nss file (assuming that is the sock file in question). Shouldn't this be there on my affected machine either? (Need more time to test more stuff, maybe this is just due to SSHing VS graphical user login - I don't know much about that stuff.)

Also I haven't tried a full selinux relable yet, I'd like to investigate this some more until I try that. Otherwise the system runs stable albeit a bit slow (might be due to drivers, another thing to investigate in more time).

ISTM that anaconda-generator shouldn't even be running on an installed system.

$ locate anaconda-genera
/usr/lib/systemd/system-generators/anaconda-generator

$ rpm -qf /usr/lib/systemd/system-generators/anaconda-generator
anaconda-core-41.35-2.fc41.x86_64

$ head -10 /usr/lib/systemd/system-generators/anaconda-generator
#!/usr/bin/bash
# anaconda-generator: generate services needed for anaconda operation

# only run in the Anaconda installation environment
ANACONDA_TARGET="/lib/systemd/system/anaconda.target"
CURRENT_DEFAULT_TARGET=$(readlink /etc/systemd/system/default.target)

if ! { [ "$ANACONDA_TARGET" = "$CURRENT_DEFAULT_TARGET" ] || grep -q 'systemd.unit=anaconda.target' /proc/cmdline ;} ; then
    exit 0
fi

$ readlink /etc/systemd/system/default.target
/usr/lib/systemd/system/graphical.target

$ cat /proc/cmdline
BOOT_IMAGE=(hd0,gpt2)/vmlinuz-6.11.7-300.fc41.x86_64 root=UUID=a38a9b84-7b9e-4d5e-9097-b1460f294a4b ro rootflags=subvol=root rhgb quiet

Continuing:

$ sudo find / -context \*anaconda\*
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/usr/lib/systemd/system-generators/anaconda-generator

$ ll -Z /usr/lib/systemd/system-generators/anaconda-generator
-rwxr-xr-x. 1 root root system_u:object_r:anaconda_generator_exec_t:s0 1605 Oct 17 08:58 /usr/lib/systemd/system-generators/anaconda-generator

Restorecon did nothing on the nss file, so probably not an issue to be solved with relabeling. Looking a bit closer there, I'm pretty sure the nss file and also a few other files in the "private" subdirectory are dangling sockets, probably left over from a crash in 2020:

[root@David-UB private]# pwd
/var/lib/sss/pipes/private
[root@David-UB private]# ll
total 0
lrwxrwxrwx. 1 root root 56  1. Nov 2020  sbus-dp_implicit_files -> /var/lib/sss/pipes/private/sbus-dp_implicit_files.203061
srw-------. 1 root root  0  1. Nov 2020  sbus-dp_implicit_files.203061
srw-------. 1 root root  0  1. Nov 2020  sbus-monitor
(Those are two more sockets and a symlink.)

Access times are the the same and I couldn't find any connected processes with lsof. After renaming the nss file the selinux alerts are gone, I guess I can just remove all of those. On my other PC those directories are empty and sssd is not running on either.

Thanks for your fast response, Steve. If I understand you correctly my selinux alerts made you poke a bit deeper and what you found might be a general mistake in Fedora, not on my machine specifically, correct?

My main goal in creating this issue was to document it in case other users get the same errors. I have no deeper knowledge of anaconda or systemd but I'll try to help you when I can, just let me know if you need anything.

I guess you could reproduce my behavior like this:
[root]# cd /var/lib/sss/pipes
[root]# nc -Ul nss

I also tried with an empty regular file (i.e. rm nss ; touch nss) and got even more selinux denials.

I am not an selinux maintainer, but I do have some experience debugging selinux issues.

My test system is F41 Workstation freshly installed in a VM.

Could you run these commands, so that we can compare the results?

$ sudo ls -alFZ /var/lib/sss/pipes/private # The -Z option displays the selinux label for files and directories.
total 0
drwxrwx---. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0  0 Oct 15 00:00 ./
drwxrwxr-x. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0 14 Oct 24 14:50 ../

My test system has these anaconda packages:

$ dnf list --installed \*anaconda\*
Installed packages
anaconda.x86_64                  41.35-2.fc41                   anaconda
anaconda-core.x86_64             41.35-2.fc41                   anaconda
anaconda-gui.x86_64              41.35-2.fc41                   anaconda
anaconda-install-env-deps.x86_64 41.35-2.fc41                   anaconda
anaconda-live.noarch             41.35-2.fc41                   anaconda
anaconda-tui.x86_64              41.35-2.fc41                   anaconda
anaconda-widgets.x86_64          41.35-2.fc41                   anaconda
kdump-anaconda-addon.noarch      006-12.20220714git7ca2d3e.fc41 anaconda
libreport-anaconda.x86_64        2.17.15-3.fc41                 anaconda

$ sudo systemctl start plocate-updatedb.service # This is just to refresh the plocate database.
$ locate anaconda-genera

$ sudo find / -context \*anaconda\*

This is the package associated with the directory:

$ rpm -qf /var/lib/sss/pipes/private/
sssd-common-2.10.0-1.fc41.x86_64

And these are the corresponding systemd services that are loaded:

$ systemctl list-units -a sssd\*
  UNIT             LOAD   ACTIVE   SUB     DESCRIPTION                                 
  sssd-kcm.service loaded active   running SSSD Kerberos Cache Manager
  sssd.service     loaded inactive dead    System Security Services Daemon             
  sssd-kcm.socket  loaded active   running SSSD Kerberos Cache Manager responder socket

sssd.service is enabled but not running::

$ systemctl -l --no-pager status sssd.service
○ sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)
  Condition: start condition unmet at Mon 2024-11-11 23:11:25 GMT; 33min ago
             ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met
             └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met

Nov 11 23:11:25 fedora-workstation-1 systemd[1]: sssd.service - System Security Services Daemon was skipped because no trigger condition checks were met.

Of course:

[da@David-UB ~]$  sudo ls -alFZ /var/lib/sss/pipes/private
[sudo] password for da: 
total 12
drwxrwx---. 3 sssd sssd system_u:object_r:sssd_var_lib_t:s0     4096 11. Nov 23:56 ./
drwxrwxr-x. 3 sssd sssd system_u:object_r:sssd_var_lib_t:s0     4096 11. Nov 23:55 ../
drwxr-xr-x. 2 root root unconfined_u:object_r:sssd_var_lib_t:s0 4096 11. Nov 23:56 oldstuff_2024-11-11/    # I moved everything here planning to delete it later - I hope this didn't mess up the results for you.
[da@David-UB ~]$  sudo ls -alFZ /var/lib/sss/pipes/private/oldstuff_2024-11-11/
total 8
drwxr-xr-x. 2 root root unconfined_u:object_r:sssd_var_lib_t:s0 4096 11. Nov 23:56 ./
drwxrwx---. 3 sssd sssd system_u:object_r:sssd_var_lib_t:s0     4096 11. Nov 23:56 ../
lrwxrwxrwx. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0   56  1. Nov 2020  sbus-dp_implicit_files -> /var/lib/sss/pipes/private/sbus-dp_implicit_files.203061
srw-------. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0    0  1. Nov 2020  sbus-dp_implicit_files.203061=
srw-------. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0    0  1. Nov 2020  sbus-monitor=
[da@David-UB ~]$ sudo dnf list --installed \*anaconda\*
Installed packages
anaconda.x86_64                  41.35-2.fc41                   fedora
anaconda-core.x86_64             41.35-2.fc41                   fedora
anaconda-gui.x86_64              41.35-2.fc41                   fedora
anaconda-install-env-deps.x86_64 41.35-2.fc41                   fedora
anaconda-tui.x86_64              41.35-2.fc41                   fedora
anaconda-widgets.x86_64          41.35-2.fc41                   fedora
kdump-anaconda-addon.noarch      006-12.20220714git7ca2d3e.fc41 fedora
libreport-anaconda.x86_64        2.17.15-3.fc41                 fedora
[da@David-UB ~]$ sudo systemctl start plocate-updatedb.service
[da@David-UB ~]$ locate anaconda-genera
/usr/lib/systemd/system-generators/anaconda-generator
[da@David-UB ~]$ sudo find / -context \*anaconda\*
find: ‘/run/user/1000/gvfs’: Permission denied
find: ‘/run/user/1000/doc’: Permission denied
/usr/lib/systemd/system-generators/anaconda-generator
[da@David-UB 1~]$ ls -alFZ /usr/lib/systemd/system-generators/anaconda-generator
-rwxr-xr-x. 1 root root system_u:object_r:anaconda_generator_exec_t:s0 1605 17. Okt 10:58 /usr/lib/systemd/system-generators/anaconda-generator*


Nothing here looks surprising to me, but maybe you'll see something that I missed?

To your second message:

[da@David-UB ~]$ rpm -qf /var/lib/sss/pipes/private/
sssd-common-2.10.0-1.fc41.x86_64
[da@David-UB ~]$ systemctl list-units -a sssd\*
  UNIT             LOAD   ACTIVE SUB     DESCRIPTION                                 
  sssd-kcm.service loaded active running SSSD Kerberos Cache Manager                 
  sssd-kcm.socket  loaded active running SSSD Kerberos Cache Manager responder socket

Legend: LOAD   → Reflects whether the unit definition was properly loaded.
        ACTIVE → The high-level unit activation state, i.e. generalization of SUB.
        SUB    → The low-level unit activation state, values depend on unit type.

2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.
[da@David-UB ~]$ systemctl -l --no-pager status sssd.service
○ sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: inactive (dead)


This looks like I had disabled the sssd service, I honestly can't remember but it is possible I did that for some reason.

$ sudo tree /etc/sssd/
/etc/sssd/
├── conf.d
└── pki

3 directories, 0 files

-> I guess this wouldn't really do anything on my system either.

This system has been upgraded and was never reinstalled since 2015 so it is very well possible that I just accumulated some minor issues here.

Anyway, thanks for further looking into it!

My top concern is that anaconda-generator seems to be running when it shouldn't be, so lets see if I can reproduce the problem in my VM.

> I also tried with an empty regular file (i.e. rm nss ; touch nss) and got even more selinux denials.

Good idea!

Could you post the output from "sudo ls -alFZ <full path to file>" for that file?

>      Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; preset: enabled)

I have disabled sssd.service and restarted:

$ systemctl list-unit-files -a sssd-kcm.service sssd-kcm.socket sssd.service
UNIT FILE        STATE    PRESET  
sssd-kcm.service indirect disabled
sssd.service     disabled enabled 
sssd-kcm.socket  enabled  enabled 

$ systemctl list-units -a sssd\*
  UNIT             LOAD   ACTIVE SUB     DESCRIPTION                                 
  sssd-kcm.service loaded active running SSSD Kerberos Cache Manager                 
  sssd-kcm.socket  loaded active running SSSD Kerberos Cache Manager responder socket

It's just touched as root:

[root@David-UB ~]# touch /var/lib/sss/pipes/nss
[root@David-UB ~]# sudo ls -alFZ /var/lib/sss/pipes/nss 
-rw-r--r--. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0 0 12. Nov 01:30 /var/lib/sss/pipes/nss

Actually I got a Selinux alert right away without even restarting systemd or doing anything else:

-----
SELinux is preventing 60-flatpak-syst from write access on the file nss.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that 60-flatpak-syst should be allowed write access on the nss 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 '60-flatpak-syst' --raw | audit2allow -M my-60flatpaksyst
# semodule -X 300 -i my-60flatpaksyst.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                unconfined_u:object_r:sssd_var_lib_t:s0
Target Objects                nss [ file ]
Source                        60-flatpak-syst
Source Path                   60-flatpak-syst
-----

With a systemctl daemon-reload I get the same alert again together with the anaconda-generator. Have you tried that in your VM? 

I'm heading to bed now, will try to answer further queries tomorrow ;)

I have this, but no AVCs:

$ ls -alFZ /var/lib/sss/pipes
total 0
drwxrwxr-x. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0     20 Nov 12 00:39 ./
drwxrwxr-x. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0     86 Oct 24 14:50 ../
-rw-r--r--. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0  0 Nov 12 00:39 nss
drwxrwx---. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0      0 Nov 12 00:39 private/

To get more information, full auditing can be enabled.

Full instructions are here:

https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing

However, if you can reproduce the AVC by running "systemctl daemon-reload", the following procedure can be used.

The procedure here is more verbose than needed, because it verifies each step:

# auditctl -l # check for current rules; there are none on my F41 Workstation VM
No rules

# auditctl -D # delete all rules, in case there are any
No rules

# auditctl -l # verify
No rules

# auditctl -w /etc/shadow -p w # enable full auditing
Old style watch rules are slower

# auditctl -l # verify
-w /etc/shadow -p w

# systemctl daemon-reload # trigger AVCs

# ausearch -i -ts boot -m avc # list any AVCs that occurred

The default rules can be restored by restarting.

If this file exists, the default rules can be restored from the command-line:

# ll /etc/audit/rules.d/audit.rules # this is from my F40 VM host
-rw-------. 1 root root 284 Apr 23  2021 /etc/audit/rules.d/audit.rules

# auditctl -R /etc/audit/rules.d/audit.rules

# auditctl -l # verify

NB: Full auditing can slow down your system.

Documentation:

$ whatis auditctl audit.rules
auditctl (8)         - a utility to assist controlling the kernel's audit system
audit.rules (7)      - a set of rules loaded in the kernel audit system

> Source                        60-flatpak-syst

That's another generator:

$ locate 60-flatpak-syst
/usr/lib/systemd/system-environment-generators/60-flatpak-system-only

$ rpm -qf /usr/lib/systemd/system-environment-generators/60-flatpak-system-only
flatpak-1.15.10-1.fc41.x86_64

(In reply to Steve from comment #17)
> /usr/lib/systemd/system-environment-generators/60-flatpak-system-only

That's a very simple shell script:

$ cat /usr/lib/systemd/system-environment-generators/60-flatpak-system-only
#!/usr/bin/sh
export GIO_USE_VFS=local
exec flatpak --print-updated-env --print-system-only

$ ls -alFZ /usr/lib/systemd/system-environment-generators/60-flatpak-system-only
-rwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 92 Aug 14 09:48 /usr/lib/systemd/system-environment-generators/60-flatpak-system-only*

> Actually I got a Selinux alert right away without even restarting systemd or doing anything else:

That suggests that a process has a watch on /var/lib/sss/pipes:

fanotify (7)         - monitoring filesystem events

This might suggest something:

$ sudo lsof -wl +c0 +D /var/lib

Here is something else to check:

$ authselect current
Profile ID: local
Enabled features:
- with-silent-lastlog
- with-mdns4
- with-fingerprint

$ authselect list
- local  	 Local users only
- nis    	 Enable NIS for system authentication
- sssd   	 Enable SSSD for system authentication (also for local users only)
- winbind	 Enable winbind for system authentication

Authselect in Fedora Linux 40: Migrating to the new “local” profile
https://fedoramagazine.org/authselect-in-fedora-linux-40-migrating-to-the-new-local-profile/

After running this, all "heck" broke loose: :-)

$ sudo authselect select sssd
Profile "sssd" was selected.

Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.

$ sudo auditctl -w /etc/shadow -p w
Old style watch rules are slower

$ sudo auditctl -l
-w /etc/shadow -p w

$ sudo systemctl daemon-reload ; date -R
Tue, 12 Nov 2024 08:15:29 +0000

$ sudo ausearch -i -ts 08:15:29 -m avc | fgrep AVC | wc -l
30

Just one example is enough to show that systemd is actually triggering the AVCs:

$ sudo ausearch -i -ts 08:15:29 -m avc | head -8
----
type=PROCTITLE msg=audit(11/12/2024 08:16:44.371:1231) : proctitle=(systemd) 
type=PATH msg=audit(11/12/2024 08:16:44.371:1231) : item=0 name=/var/lib/sss/pipes/nss inode=309103 dev=00:28 mode=file,644 ouid=root ogid=root rdev=00:00 obj=unconfined_u:object_r:sssd_var_lib_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(11/12/2024 08:16:44.371:1231) : cwd=/ 
type=SOCKADDR msg=audit(11/12/2024 08:16:44.371:1231) : saddr={ saddr_fam=local path=/var/lib/sss/pipes/nss } 
type=SYSCALL msg=audit(11/12/2024 08:16:44.371:1231) : arch=x86_64 syscall=connect success=no exit=EACCES(Permission denied) a0=0x8 a1=0x7ffe66203b70 a2=0x6e a3=0x100 items=1 ppid=1 pid=4944 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=16 comm=(systemd) exe=/usr/lib/systemd/systemd-executor subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(11/12/2024 08:16:44.371:1231) : avc:  denied  { write } for  pid=4944 comm=(systemd) name=nss dev="vda3" ino=309103 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:object_r:sssd_var_lib_t:s0 tclass=file permissive=0 
----

NB: /var/lib/sss/pipes/nss is the empty file previously created:

$ sudo ls -alFZ /var/lib/sss/pipes/
total 0
drwxrwxr-x. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0     20 Nov 12 00:39 ./
drwxrwxr-x. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0     86 Oct 24 14:50 ../
-rw-r--r--. 1 root root unconfined_u:object_r:sssd_var_lib_t:s0  0 Nov 12 00:39 nss
drwxrwx---. 1 sssd sssd system_u:object_r:sssd_var_lib_t:s0      0 Nov 12 00:39 private/

And sssd.service is disabled:

$ systemctl list-unit-files -a sssd.service
UNIT FILE    STATE    PRESET 
sssd.service disabled enabled

Can you see if this suppresses the AVCs?

$ sudo authselect select local
Profile "local" was selected.

$ sudo systemctl daemon-reload ; date -R
Tue, 12 Nov 2024 08:32:59 +0000

$ sudo ausearch -i -ts 08:32:59 -m avc
<no matches>

After that we can try reselecting "sssd" and following this advice from Comment 21:

"Make sure that SSSD service is configured and enabled."

Further to comment 20 above and looking at "Authselect in Fedora Linux 40: Migrating to the new “local” profile
https://fedoramagazine.org/authselect-in-fedora-linux-40-migrating-to-the-new-local-profile/ "

I found that 

 sudo authselect select local with-silent-lastlog with-mdns4  --force

Has got rid of these selinux alarms on my 4-year-old system.

*** Bug 2328882 has been marked as a duplicate of this bug. ***

*** Bug 2330049 has been marked as a duplicate of this bug. ***

Hey Steve,
I'm very sorry I didn't get back to you and at the same time very grateful that you hinted me towards a potential issue with the [now confirmed missing] authselect configuration on my system: After the upgrade to F43 the graphical login was missing but with that potential issue in the back of my mind it was a relatively easy fix! [1]

This issue can be closed, it is not a selinux issue but something which accumulated during upgrades and half broken configs around authselect and sssd.

Thanks again!

David



1: More on my login issue caused by missing authselect configuration - https://discussion.fedoraproject.org/t/no-login-screen-after-upgrade-to-f43-solved-authselect-was-never-set-up-on-a-system-upgraded-through-many-versions/170594

This message is a reminder that Fedora Linux 41 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 41 on 2025-12-15.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '41'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 41 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.