Bug 2415883

We (osbuild/image-builder) started noticing the same in our CI where we are no longer able to log in to freshly built Fedora 42 systems over SSH with the same AVC denial.

Hi,

Can you run the following commands?

rpm -qa "selinux-policy*"
getsebool unconfined_login
ls -lZa /usr/libexec/openssh/
restorecon -Rvn /usr/libexec/openssh/

This part is particularly suspicious:
comm="sshd-session" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023

(In reply to Simon de Vlieger from comment #1)
> We (osbuild/image-builder) started noticing the same in our CI where we are
> no longer able to log in to freshly built Fedora 42 systems over SSH with
> the same AVC denial.

As I haven't seen such denials during numerous tests, I expect it can be related to immutable mode. 
Changes made by selinux-policy-42.10-1 need to result in context changes on the filesystem.

These AVC denials are seen on package based systems installed by an Anaconda boot.iso (not image mode/immutable). I'll see if I can get you the output.

Ok, I installed a fresh VM from: https://fedora.mirror.liteserver.nl/linux/releases/42/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-42-1.1.iso which exhibits the behavior.

audit.log contains:
```
type=AVC msg=audit(1763568225.806:131): avc:  denied  { dyntransition } for  pid=922 comm="sshd-session" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0
```

and for the commands you asked for:
```
[root@fedora ~]# rpm -qa "selinux-policy*"
selinux-policy-42.14-1.fc42.noarch
selinux-policy-targeted-42.14-1.fc42.noarch
[root@fedora ~]# getsebool unconfined_login
unconfined_login --> on
[root@fedora ~]# ls -lZa /usr/libexec/openssh/
total 1552
drwxr-xr-x. 1 root root system_u:object_r:bin_t:s0                 180 Nov 19 16:57 .
drwxr-xr-x. 1 root root system_u:object_r:bin_t:s0                1006 Nov 19 16:57 ..
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0               82416 May 19  2025 sftp-server
-rwxr-xr-x. 1 root root system_u:object_r:sshd_keygen_exec_t:s0    904 May 19  2025 sshd-keygen
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0              969512 May 19  2025 sshd-session
-rwxr--r--. 1 root root system_u:object_r:bin_t:s0                1714 May 19  2025 ssh-host-keys-migration.sh
-rwxr-xr-x. 1 root root system_u:object_r:ssh_agent_exec_t:s0   255248 May 19  2025 ssh-pkcs11-helper
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0              263448 May 19  2025 ssh-sk-helper
[root@fedora ~]# restorecon -Rvn /usr/libexec/openssh/
Would relabel /usr/libexec/openssh/sshd-session from system_u:object_r:bin_t:s0 to system_u:object_r:sshd_session_exec_t:s0
```

I can confirm that when trying `restorecon -Rv /usr/libexec/openssh/` I'm able to login to the machine using ssh.

I can also confirm that the output of the commands is the same as for Simon de Vlieger.

I've seen this on a few f43 vm's we just installed. It seems like it might be some kind of race, as most of the time things are fine?

Fwiw I also see it on f44, here is the log from one of our automatic tests:
https://gitlab.com/redhat/services/products/image-builder/ci/images/-/jobs/12182662239#L4430
```
[   20.697283] sshd-session[763]: fatal: sshd_selinux_copy_context: setcon failed with Permission denied
```
is there error.

(In reply to Michael Vogt from comment #8)
> Fwiw I also see it on f44, here is the log from one of our automatic tests:
> https://gitlab.com/redhat/services/products/image-builder/ci/images/-/jobs/
> 12182662239#L4430
> ```
> [   20.697283] sshd-session[763]: fatal: sshd_selinux_copy_context: setcon
> failed with Permission denied
> ```
> is there error.

There are neither avc denials nor selinux_err ones, can you find them in another log?
Can you check labels of files in /usr/libexec/openssh?
New labels were assigned in selinux-policy-42.10-1 at Tue Sep 16 2025.

As this bug has been in NEEDINFO state for an extended period of time, we are going to close this bug due to inactivity. If you want to pursue this matter further, feel free to reopen this bug and attach the needed information.