Skip to content

Conversation

@HastD
Copy link
Collaborator

@HastD HastD commented Sep 15, 2025

Currently flatpak is not compatible with SELinux confined users: the flatpak executable does not have the necessary permissions to create the sandbox. This policy solves this by confining the flatpak program itself (and the helper programs it calls, such as bwrap) in an application domain with the necessary permissions, which transitions back into the user domain to run the sandboxed flatpak application.

For example, if a staff_u user runs a flatpak application from the user domain staff_t, flatpak will run in staff_flatpak_t, while the app will run in staff_t.

The policy also includes more fine-grained labeling for flatpak app library files, data files, cache files, and temporary files.

A couple logistical notes:

  • The policy module is named "flatpak-sandbox" rather than just "flatpak" because flatpak itself ships with a policy module called "flatpak", which is used to grant a few extra permissions to flatpak-system-helper, and we don't want to accidentally override that policy.
  • This PR does not include Trivalent-Flatpak integration; I figure that should be part of the Trivalent policy, which in any case will need to be revised to work with confined users.

RoyalOughtness and others added 15 commits October 26, 2025 03:14
This workflow runs the following steps daily:

* Pull tags from upstream;
* Rebase the default branch onto the latest tag for the current Fedora
  version;
* Push the changes to the default branch, including tags.

If the rebase encounters conflicts, the job will abort and conflicts
will need to be resolved manually.

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
This makes the action sync the repo with the upstream tag that the
selinux-policy RPM spec for the current Fedora version uses, not the
most recent tag (which is often only on rawhide, not stable).

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
Extract the commit hash from the selinux-policy RPM spec for the current
Fedora version and use that as the base for the rebase. This ensures
that the upstream sync works even if the commit isn't tagged.

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
e -> f

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
…ue#9)

* ci: push merged lightweight tags in sync workflow

Since `--follow-tags` only pushes annotated tags, we need to separately
list merged tags and push them by name.

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>

* ci: skip unnecessary rebases in sync workflow

If the commit we would rebase to is already present on the working
branch, we skip the rebase since that means we wouldn't be pushing any
new commits.

---------

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
* chore: add bot for rebasing

* newbotmethod
HastD added 4 commits October 31, 2025 20:10
Currently flatpak is not compatible with SELinux confined users: the
flatpak executable does not have the necessary permissions to create the
sandbox. This policy solves this by confining the flatpak program itself
(and the helper programs it calls, such as bwrap) in an application
domain with the necessary permissions, which transitions back into the
user domain to run the sandboxed flatpak application.

For example, if a `staff_u` user runs a flatpak application from the
user domain `staff_t`, flatpak will run in `staff_flatpak_t`, while
the app will run in `staff_t`.

The policy also includes more fine-grained labeling for flatpak app
library files, data files, cache files, and temporary files.

Signed-off-by: Daniel Hast <hast.daniel@protonmail.com>
Fixes denials that newly show up with this policy in Fedora 43.
@secureblue-bot secureblue-bot force-pushed the f42-secureblue branch 2 times, most recently from 4a092d9 to ccea390 Compare November 27, 2025 03:16
@secureblue-bot secureblue-bot force-pushed the f42-secureblue branch 2 times, most recently from 316918e to 1f16bed Compare December 8, 2025 02:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants