Bug 2540774

Summary:	selinux-policy update breaks SSH port forwarding to Unix sockets
Product:	[Fedora] Fedora	Reporter:	nik <nikita>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	NEW ---	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	44	CC:	dwalsh, lvrabec, mmalik, omosnacek, pkoncity, vmojzis, zpytela
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	---
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description nik 2026-09-24 19:56:55 UTC

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.)

Comment 1 Zdenek Pytela 2026-09-25 10:02:35 UTC

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.

Comment 2 nik 2026-09-26 12:01:43 UTC

> 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.