### Summary Git operations over SSH fail for all users when SELinux is in Enforcing mode on RHEL 10 / AlmaLinux 10. `sshd-session` runs in the new `sshd_session_t` domain (introduced by the OpenSSH 9.x "sshd-session split"), but the SELinux policy shipped by omnibus-gitlab (`gitlab-13.5.0-gitlab-shell`, `gitlab-10.5.0-ssh-authorized-keys`) only grants `sshd_t` permission to read the `gitlab_shell_t`-labeled `/var/opt/gitlab/.ssh/authorized_keys`. Every key registered in GitLab is therefore rejected at the SSH layer. This is a regression from the OpenSSH sshd-session split: the same class of breakage was fixed upstream for the Fedora/RHEL policy (e.g. fedora-selinux/selinux-policy#3243, #3286, #3288), and the older variant of this bug for `sshd_t` on CentOS 8 was omnibus-gitlab#6397 (fixed in 16.0) — but the policy was never updated for `sshd_session_t`. ### Steps to reproduce 1. Install GitLab CE (e.g. 19.2.1) on AlmaLinux 10 / RHEL 10 with SELinux Enforcing (default). 2. Add an SSH key to a user profile. 3. Attempt a git operation over SSH (`ssh -T git@hostname` or `git clone`). ### What is the current bug behavior? All SSH requests for the `git` user fail with `Permission denied (publickey,...)` and fall back to prompting for a password. No `gitlab-shell` log entries are produced because gitlab-shell never executes. Keys are registered in GitLab (visible via the API) and previously worked before the upgrade that introduced `sshd-session`. ### What is the expected correct behavior? SSH requests succeed and git operations are authorized using keys registered in GitLab. ### Relevant logs `journalctl -u sshd`: ``` Aug 12 00:22:28 gitlab sshd-session[113637]: Could not open user 'git' authorized keys '/var/opt/gitlab/.ssh/authorized_keys': Permission denied Aug 12 00:22:28 gitlab sshd-session[113637]: Failed password for git from ... ssh2 ``` `/var/log/audit/audit.log` (AVC, logged with `permissive=0`): ``` avc: denied { search } for comm="sshd-session" name=".ssh" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=...:gitlab_shell_t:s0 tclass=dir permissive=0 avc: denied { read } for comm="sshd-session" name="authorized_keys" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=...:gitlab_shell_t:s0 tclass=file permissive=0 avc: denied { open } for comm="sshd-session" path="/var/opt/gitlab/.ssh/authorized_keys" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=...:gitlab_shell_t:s0 tclass=file permissive=0 avc: denied { getattr } for comm="sshd-session" path="/var/opt/gitlab/.ssh/authorized_keys" scontext=system_u:system_r:sshd_session_t:s0-s0:c0.c1023 tcontext=...:gitlab_shell_t:s0 tclass=file permissive=0 ``` ### Details of package version ``` $ rpm -q gitlab-ce openssh-server gitlab-ce-19.2.1-ce.0.el10.x86_64 openssh-server-9.9p1-25.el10_2.alma.1.x86_64 ``` ### Environment details * Operating System: AlmaLinux 10.2 (Lavender Lion), SELinux Enforcing (targeted) * Installation Target: Bare metal * Installation Type: Omnibus RPM, single node * Is this a single or multiple node installation? Single ### Configuration details Legacy `auth_file` mode is in use: ```yaml # /var/opt/gitlab/gitlab-shell/config.yml auth_file: "/var/opt/gitlab/.ssh/authorized_keys" ``` ### Background: when the SSH domains split * OpenSSH **9.8** (released 2024-07-01) split the daemon upstream: "the server has been split into a listener binary, `sshd(8)`, and a per-session binary `sshd-session`" ([release notes](https://www.openssh.com/txt/release-9.8)). * The SELinux domain split landed in the Fedora/RHEL policy with commit `efa131d050dd6` "Define types for new openssh executables" (authored 2025-05-23, merged 2025-09-16), introducing `sshd_session_t` / `sshd_session_exec_t`. It shipped in **Fedora 41 (openssh 9.9)** and **RHEL 10**, i.e. the exact combination affected here (`openssh-server-9.9p1` on AlmaLinux 10). * Upstream has already split further: **OpenSSH 10.0 / Fedora 43** moves the user-authentication phase from `sshd-session` into a new `sshd-auth` binary with a third domain `sshd_auth_t` — the same compatibility concern will apply to GitLab's policy again, so it is worth handling both domains now. ### Root cause `files/gitlab-selinux/gitlab-13.5.0-gitlab-shell.te` (and the installed modules) only contain rules for `sshd_t`: ``` allow sshd_t gitlab_shell_t:file read; allow sshd_t gitlab_shell_t:file open; allow sshd_t gitlab_shell_t:file getattr; ``` On RHEL 10 / AlmaLinux 10, OpenSSH 9.9 runs authentication in `sshd_session_t` instead of `sshd_t`, so these rules are never applied. The Fedora/RHEL policy maintainers already migrated equivalent rules to `sshd_session_t` for their own types; GitLab's bundled module has not. ### Workaround Install a local SELinux policy module allowing `sshd_session_t` to read the GitLab key store: ```te module gitlab_sshd_keys 1.0; require { type sshd_session_t; type gitlab_shell_t; class dir { search getattr read open }; class file { getattr open read }; } allow sshd_session_t gitlab_shell_t:dir { search getattr read open }; allow sshd_session_t gitlab_shell_t:file { getattr open read }; ``` ```sh checkmodule -M -m -o gitlab_sshd_keys.mod gitlab_sshd_keys.te semodule_package -o gitlab_sshd_keys.pp -m gitlab_sshd_keys.mod sudo semodule -i gitlab_sshd_keys.pp ``` ### Suggested fix Add the equivalent `sshd_session_t` rules to `files/gitlab-selinux/` (and ship updated `.pp` modules), mirroring what the Fedora `selinux-policy` project did for its own types after the sshd-session split. Consider also the `AuthorizedKeysCommand`-based setup, which sidesteps reading the `gitlab_shell_t`-labeled file entirely. Related: omnibus-gitlab#6397, #9471; fedora-selinux/selinux-policy#3243, #3286, #3288.