Allow sshd_session_t to launch containers

[inknos]

OpenSSH 9.8+ split sshd into sshd (listener) + sshd-session (post-auth session handling). All forwarding now runs as sshd_session_t instead of sshd_t. Extend the sshd_launch_containers boolean to cover sshd_session_t so SSH -L forwarding to container runtime sockets is not denied by SELinux.

Wrapped in optional_policy so it compiles on systems without the sshd-session split (OpenSSH < 9.8).

Fixes: #478

Summary by Sourcery

Extend SELinux container policy so sshd_session_t can launch containers when the sshd_launch_containers boolean is enabled, while preserving compatibility with OpenSSH versions without sshd-session.

Bug Fixes:

• Allow SSH local forwarding to container runtime sockets to work under SELinux on systems using the split sshd/sshd-session model in OpenSSH 9.8+.

Enhancements:

• Generalize the sshd_launch_containers SELinux boolean to cover both sshd_t and sshd_session_t using optional policy so it builds on systems without sshd-session.

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

Extend the existing sshd_launch_containers SELinux boolean so that the new sshd_session_t domain (used by OpenSSH 9.8+ for post-auth session handling and forwarding) can also launch/communicate with containers, and wrap the policy in optional_policy so it safely compiles on systems without sshd_session_t (pre-9.8).

File-Level Changes

Change	Details	Files
Extend sshd_launch_containers boolean behavior from sshd_t to also cover sshd_session_t, using optional_policy for compatibility with OpenSSH versions without sshd_session_t.	Add SELinux allow/use rules for sshd_session_t that parallel the existing sshd_t container-launch permissions controlled by sshd_launch_containers Wrap sshd_session_t-related policy in an optional_policy block so the module still compiles when sshd_session_t is not defined (e.g., OpenSSH < 9.8) Ensure container runtime/socket access via SSH local forwarding works when sshd_launch_containers is enabled, by granting sshd_session_t the required container domain and socket access	container.te

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey - I've reviewed your changes and they look great!

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[gemini-code-assist]

Code Review

This pull request updates the SELinux policy in container.te to support OpenSSH 9.8+, which splits sshd into a listener and a post-auth session (sshd-session). It adds an optional policy block allowing sshd_session_t to transition to the container runtime domain when the sshd_launch_containers tunable is enabled. There are no review comments, and I have no feedback to provide.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[packit-as-a-service]

Tests failed. @containers/packit-build please check.

[inknos]

/packit retest-failed

[lsm5]

@inknos thanks. Has this been tested on the podman-py side via something like https://packit.dev/posts/testing-farm-triggering/ and/or locally? If not, would you mind doing this on a test PR on podman-py?

[lsm5]

ELN rootless tests failed on not finding user fedora. Unrelated to the PR. That needs to be fixed on the podman side.

[inknos]

for the tests, I rebased on #480

[inknos]

Has this been tested on the podman-py side via something like https://packit.dev/posts/testing-farm-triggering/ and/or locally? If not, would you mind doing this on a test PR on podman-py?

I can try with packit

[rhatdan]

I believe this should be in selinux-policy, along with the definition of the tunable.

@zpytela PTAL

[lsm5]

I believe this should be in selinux-policy, along with the definition of the tunable.

@rhatdan are you opposed to merging this here? Can we defer transfer to selinux-policy?

[zpytela]

I believe this should be in selinux-policy, along with the definition of the tunable.

@zpytela PTAL

It should rather be in selinux-policy and we discussed that earlier, but it was kind-of postponed since it requires sync of 2 components and delivering to 2+ releases which also includes reverting the change in the other ones.

[rhatdan]

Ok I will merge, and once we release this in selinux-policy, we can revert.