Fedora Account System
Red Hat Associate
Red Hat Customer
Recent updates in selinux-policy broke port forwarding for sshd. A possibly related bug: https://bugzilla.redhat.com/show_bug.cgi?id=2483760. Reproducible: Always Steps to Reproduce: Here are the full reproduction steps: First we'll demonstrate that it used to work: Install latest Fedora Server (Fedora-Server-dvd-x86_64-44-1.7.iso) with default setting. Try forwarding SSH: On the server, run: nc -lU bla.sock On the client, run: ssh -L 127.0.0.1:1234:/home/user/bla.sock user@$SERVER_IP Then, on the client, run: nc 127.0.0.1 1234 Observe that the connection works and reaches the nc on the server. Now, on the server: $ rpm -q selinux-policy selinux-policy-43.3-1.fc44.noarch Let's try upgrading the SELinux policy on the server: $ sudo dnf up -y selinux-policy $ rpm -q selinux-policy selinux-policy-44.10-1.fc44.noarch Repeat the nc setup again with the new policy. Now, we see: channel 2: open failed: connect failed: open failed In journalctl: Sep 24 15:44:17 localhost.localdomain audit[2445]: AVC avc: denied { write } for pid=2445 comm="sshd-session" name="bla.sock" dev="dm-0" ino=28277475 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=sock_file permissive=0 Sep 24 15:44:17 localhost.localdomain sshd-session[2445]: error: connect to /home/user/bla.sock port -2 failed: Permission denied $ sudo sealert -l 4b7a066c-c1bc-4d3f-8643-47df9dc265e5 SELinux is preventing sshd-session from write access on the sock_file bla.sock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that sshd-session should be allowed write access on the bla.sock sock_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 'sshd-session' --raw | audit2allow -M my-sshdsession # semodule -X 300 -i my-sshdsession.pp Additional Information: Source Context system_u:system_r:sshd_session_t:s0-s0:c0.c1023 Target Context unconfined_u:object_r:user_home_t:s0 Target Objects bla.sock [ sock_file ] Source sshd-session Source Path sshd-session Port <Unknown> Host localhost.localdomain Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-44.10-1.fc44.noarch Local Policy RPM selinux-policy-targeted-44.10-1.fc44.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name localhost.localdomain Platform Linux localhost.localdomain 6.19.10-300.fc44.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Mar 25 18:23:49 UTC 2026 x86_64 Alert Count 4 First Seen 2026-09-24 15:37:24 EDT Last Seen 2026-09-24 15:44:17 EDT Local ID 4b7a066c-c1bc-4d3f-8643-47df9dc265e5 Raw Audit Messages type=AVC msg=audit(1790279057.809:334): avc: denied { write } for pid=2445 comm="sshd-session" name="bla.sock" dev="dm-0" ino=28277475 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=sock_file permissive=0 Hash: sshd-session,sshd_session_t,user_home_t,sock_file,write Additional Information: (The update breaks a fundamental component in running systems, hence classifying as high severity.)
With allowing sshd-session write to a socket file on an arbitrary path we would significantly loosen the policy. I suggest using the /tmp path or creating a custom policy.
> allowing sshd-session write to a socket file on an arbitrary path we would significantly loosen the policy Why? The access is performed by sshd-session that runs under the permissions of the logged in user. IIUC if the user can log in they can already access any socket that is accessible to them, so I'm not sure what are the security benefits of preventing sshd-session running as said user from forwarding a port to that socket. In other words, I can "hack around" the limitation using: - forward a local port to a remote TCP port (ssh -L 127.0.0.1:1234:127.0.0.1:1234) - run socat TCP-L:1234 UNIX:bla.sock to reach the socket (But the hack is less secure since other local users on the server can now access the socket too via the intermediate port.) > I suggest using the /tmp path This is less desirable for me since then the socket would become world-visible and I have to think about name collisions from other users.