container: label /run/user/*/crun as container_var_run_t

[giuseppe]

Closes: #404

Summary by Sourcery

Add SELinux policy to label /run/user/*/crun with container_var_run_t

Bug Fixes:

• Fix SELinux denials for crun by assigning the correct file context for /run/user/*/crun

Enhancements:

• Label the /run/user/*/crun path as container_var_run_t in the SELinux policy to allow crun access in rootless containers

[sourcery-ai]

Reviewer's guide (collapsed on small PRs)

Reviewer's Guide

This PR extends the SELinux policy to label the per‐user crun socket directory under /run/user/*/crun as container_var_run_t, ensuring proper confinement for crun’s control directory.

File-Level Changes

Change	Details	Files
Add SELinux file context rule for /run/user/*/crun	Add regex '/run/user/[0-9]+/crun(/.*)?' to file_contexts mapping to container_var_run_t	container.fc
Register crun directory in TE policy	Invoke control_dir macro for var_run_user_crun to handle '/run/user/*/crun' as container_var_run_t	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.

[gemini-code-assist]

Summary of Changes

Hello @giuseppe, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an SELinux labeling discrepancy for container runtime files located in user-specific temporary directories. By adding a new policy rule, it ensures that these files are correctly labeled, which is crucial for maintaining the security and proper functioning of containerized applications.

Highlights

• SELinux Policy Update: Introduces a new SELinux rule to correctly label temporary files and directories within user-specific runtime paths (e.g., /run/user/*/crun) as container_var_run_t.
• Enhanced Container Security: Ensures that container runtime components like crun operating in user-specific environments have the appropriate security context, resolving potential access or permission issues.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in issue comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[sourcery-ai]

Hey there - 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.}

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: giuseppe, sourcery-ai[bot]
Once this PR has been reviewed and has the lgtm label, please assign rhatdan for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[gemini-code-assist]

Code Review

This pull request addresses an issue with rootless Podman on systems with SELinux enabled by updating the container SELinux policy. The change introduces a file transition rule using userdom_user_tmp_filetrans to ensure that files and directories created by the container runtime under /run/user/ are correctly labeled as container_var_run_t. This is a correct and targeted fix for the reported AVC denials. The implementation is clean and follows existing patterns in the policy file. I have no suggestions for improvement.

[rhatdan]

LGTM

[Luap99]

The closes doesn't link to #404 but the podman issue is that right?
If that changes the label of the podman runroot it must be coordinated with the pasta policy as it depends on the user_tmp_t context currently

[giuseppe]

The closes doesn't link to #404 but the podman issue is that right?

yeah that was wrong, thanks, fixed now.

If that changes the label of the podman runroot it must be coordinated with the pasta policy as it depends on the user_tmp_t context currently

I've tested the new policy and pasta seems to work fine with it:

➜ ls -nlZ /run/user/1000/netns/
total 0
-rw-------. 1 1000 1000 unconfined_u:object_r:ifconfig_var_run_t:s0 0 Sep 11 15:46 netns-056eb537-9d9b-a3ca-5bb4-2e1faad099c5
➜ ls -nlZ /run/user/1000/containers/networks/
total 0
drwx------. 2 1000 1000 unconfined_u:object_r:container_var_run_t:s0 40 Sep 11 15:45 rootless-netns

[Luap99]

If you install this update from podman-next this update it is clearly broken now with pasta

$ podman run --network bridge quay.io/libpod/testimage:20241011 true
Error: setting up Pasta: pasta failed with exit code 1:
Couldn't open PID file /run/user/1000/containers/networks/rootless-netns/rootless-netns-conn.pid: Permission denied

The podman tmt tests are failing now because of this https://artifacts.dev.testing-farm.io/2edbf35e-bee1-4913-b0ab-7cb340323048/

If this is the proper label then as I said we must coordinate this with a pasta policy update

[Luap99]

Oh and of course the title here is misleading since the commit didn't just chnage the label for /run/user/*/crun but the at least the podman directories /run/user/*/containers and /run/user/*/libpod as well

[sbrivio-rh]

@rhatdan this breaks things quite badly. Before we get a disproportionate amount of issues about pasta(1) not starting, can we revert this quick?

By the way, @Luap99 also reported this before this was merged:

If that changes the label of the podman runroot it must be coordinated with the pasta policy as it depends on the user_tmp_t context currently

...but we clearly didn't have time, nor the indication, to change something in pasta's policy as a result.

To prevent this kind of breakage in the future, can a test run perhaps be enforced as part of the integration process? Podman has a ton of tests executing quickly and reliably, and it looks like a shame not to use those.

All related projects have some form of continuous integration testing, just not this one. In the pasta(1) test suite itself, we enforce running networking tests from Podman's HEAD.

[Luap99]

I send a patch to pasta to adapt the policy there https://archives.passt.top/passt-dev/20250917120450.36181-2-pholzing@redhat.com/

To prevent this kind of breakage in the future, can a test run perhaps be enforced as part of the integration process? Podman has a ton of tests executing quickly and reliably, and it looks like a shame not to use those.

I think we run a subset of tests here via tmt but not sure if we run both root AND rootless here? And if the subset contains the right trigger since it requires the use of the custom network.
If we run the tests from 500-networking.bats as rootless we should be able to catch any pasta releated problems if this policy here changes in an incompatible way.
cc @lsm5

[rhatdan]

Please open a PR to change it back.

[rhatdan]

If this is only supposed to change the label on the crun directory, can we just do:

userdom_user_tmp_filetrans(container_runtime_domain, container_var_run_t, { dir file lnk_file sock_file }, "crun")

Totally untested.

[giuseppe]

that seems to work in my environment.

@Luap99 I see you've prepared some patches for pasta as well, what version do you prefer?

If we create all the files/dirs with container_var_run_t then we behave closer to what rootful Podman does, but might have other surprises

[Luap99]

that seems to work in my environment.

Did you reboot? The tmpfiles are only created the first time around and then keep its context of course, so without a relabel this should only be noticeable after boot. And of course there is the issues of relabel rules can be different from transition rules.

@Luap99 I see you've prepared some patches for pasta as well, what version do you prefer?

If we create all the files/dirs with container_var_run_t then we behave closer to what rootful Podman does, but might have other surprises

Well frankly I have zero idea about what each label here is supposed to represent, with the amount of similar types here (
containers/podman#26473 (comment)) I have no clue what is used where and how. And what permissions each type has and so on.

Logically having consistent behavior between root and rootless seems desirable so I am in favor of keeping this change and patch pasta's policy like I already posted. But that of course still needs to be coordinated, i.e. we cannot release this here until the pasta fix lands in fedora.

[Luap99]

But I guess container-selinux is still missing the file context rules for this change?

$ restorecon -v -R /run/user/1000/crun
Warning no default label for /run/user/1000/crun
$ restorecon -v -R /run/user/1000/containers
Warning no default label for /run/user/1000/containers
$ restorecon -v -R /run/user/1000/libpod
Warning no default label for /run/user/1000/libpod

I assume restorecon should work on these directories if we label container_var_run_t?

[giuseppe]

have you tried deleting it completely and see how it gets recreated after you run Podman?

[Luap99]

Well I rebooted for my testing so yeah, and yes the dir is container_var_run_t due the transition rule here. The point is container_var_run_t is not compatible with the current pasta policy (hence my patches to pasta). But also because there is no default file context restorecon doesn't work for existing users that upgrade on a live system which seems unexpected? I assume selinux rules should always have file context rules for the files we are supposed to label. At the very least so that restorecon doesn't mess things up?

But I guess that is not new, as root it seems to be broken as well.

$ sudo restorecon -v -R /run/crun
Relabeled /run/crun from unconfined_u:object_r:container_var_run_t:s0 to unconfined_u:object_r:var_run_t:s0
Relabeled /run/crun/.empty-directory from unconfined_u:object_r:container_var_run_t:s0 to unconfined_u:object_r:var_run_t:s0
Relabeled /run/crun/.cache from unconfined_u:object_r:container_var_run_t:s0 to unconfined_u:object_r:var_run_t:s0
Relabeled /run/crun/.cache/seccomp from unconfined_u:object_r:container_var_run_t:s0 to unconfined_u:object_r:var_run_t:s0
Relabeled /run/crun/.cache/seccomp/b366026d8efff477e3d588dc610424a0ca49b4898db0bbb4fd3e916af60132e3 from unconfined_u:object_r:container_var_run_t:s0 to unconfined_u:object_r:var_run_t:s0

So here it is even worse because restorecon will apply the var_run_t label now?
Now interestingly enough the reproducer doesn't fail with the var_run_t label because the container is allowed to read var_run_t for some reason?