Bug 2526123

I'm on selinux-policy-44.8-1.fc44.noarch and forwarding is broken.

I'm posting here since I'm doing something slightly less standard: forwarding a TCP port to a Unix socket in a container, and I got this:

sshd-session[5184]: error: connect to /********************/gui.sock port -2 failed: Permission denied
audit[5184]: AVC avc:  denied  { write } for  pid=5184 comm="sshd-session" name="gui.sock" dev="dm-1" ino=1049674 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:container_file_t:s0:c187,c529 tclass=sock_file permissive=0
audit[5184]: SYSCALL arch=c000003e syscall=42 success=no exit=-13 a0=6 a1=559928dc6150 a2=6e a3=0 items=0 ppid=5156 pid=5184 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=2 comm="sshd-session" exe="/usr/libexec/openssh/sshd-session" subj=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 key=(null)

This used to work before the update.

Also affects using a machine as a proxy/jump host (-J/-W), which I guess is very similar to port forwarding

```
type=AVC msg=audit(1788525607.537:1602298): avc:  denied  { name_connect } for  pid=3888943 comm="sshd-session" dest=22 scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=system_u:object_r:ssh_port_t:s0 tclass=tcp_socket permissive=0
```

selinux-policy-44.8-1.fc44.noarch

I'm still getting from VS Code:
Failed to set up dynamic port forwarding connection over SSH to the VS Code Server. ([Show log](command:opensshremotes.showLog "Show log"))
Remote SSH log
Failed to set up socket for dynamic port forward to remote port 42685: Socket closed. TCP port forwarding may be disabled, or the remote server may have crashed. See the VS Code Server log above for details.

I had to do the following

sudo ausearch -c 'sshd' --raw | audit2allow -M my_sshd_port
sudo semodule -i my_sshd_port.pp

as a workaround.

(In reply to ultrafilter from comment #4)
> I had to do the following
> 
> sudo ausearch -c 'sshd' --raw | audit2allow -M my_sshd_port
> sudo semodule -i my_sshd_port.pp
> 
> as a workaround.

cat my_sshd_port.te

module my_sshd_port 1.0;

require {
        type sshd_session_t;
        type ephemeral_port_t;
        type ssh_home_t;
        class sock_file { create unlink };
        class tcp_socket name_connect;
}

#============= sshd_session_t ==============

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow sshd_session_t ephemeral_port_t:tcp_socket name_connect;

#!!!! This avc is allowed in the current policy
allow sshd_session_t ssh_home_t:sock_file { create unlink };

Adding a data point: I'm trying to connect VS Code on my local machine to Fedora Server 44, using the Remote-SSH extension in VS Code.

selinux-policy-targeted.noarch                 44.8-1.fc44

Running:

sudo ausearch -c 'sshd' --raw | audit2allow -M my_sshd_port

Generated this file, which is different from the one in #4 - every require entry in this file is in the file in #4, but #4 has entries which aren't in this file. In any case, it fixed the problem when applied.

module my_sshd_port 1.0;

require {
        type ephemeral_port_t;
        type sshd_session_t;
        class tcp_socket name_connect;
}

#============= sshd_session_t ==============

#!!!! This avc can be allowed using the boolean 'nis_enabled'
allow sshd_session_t ephemeral_port_t:tcp_socket name_connect;

FEDORA-2026-1413268892 (selinux-policy-44.9-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-1413268892

FEDORA-2026-1413268892 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-1413268892`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-1413268892

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2026-1413268892 (selinux-policy-44.9-1.fc44) has been pushed to the Fedora 44 stable repository.
If problem still persists, please make note of it in this bug report.

Reopening.

I jumped straight from selinux-policy-targeted-44.4 to the selinux-policy-targeted-44.9 I just installed this morning, and I'm NOW unable to make VNC connections over forwarded TCP ports using:

#!/bin/sh
export VNC_VIA_CMD='/usr/bin/ssh -f -L "$L":"$H":"$R" "$G" sleep 2'
exec /usr/bin/vncviewer localhost:1 -via $myserver

In the server's journal, I see:

Sep 18 13:22:48 setroubleshoot[139025]: SELinux is preventing /usr/libexec/openssh/sshd-session from name_connect access on the tcp_socket port 5901.
                                        
                                        *****  Plugin catchall (100. confidence) suggests   **************************
                                        
                                        If you believe that sshd-session should be allowed name_connect access on the port 5901 tcp_socket 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


...Why was this potentially-disruptive change to the policy for sshd-session pushed to the active Fedora release (F44) at all? Making such a major change to the permissions config for a heavily-used service seems like the sort of thing that should be done only in rawhide, so it can be tested for the next distro release.

I tried selinux-policy-44.9-1.fc44, the problem I described above still persists (forwarding a TCP port to a Unix socket in a container)

The bug as reported has been resolved. For new issues please open a new bug.

issue is returning with selinux-policy-45.22, see https://bugzilla.redhat.com/show_bug.cgi?id=2560255