Enable enforcing SELinux for sealed images by jeckersb · Pull Request #2035 · bootc-dev/bootc

jeckersb · 2026-03-03T01:11:54Z

install: Label composefs objects as /usr for SELinux

The composefs object store currently has no matching SELinux policy
for its storage path, so its contents end up labeled as default_t
which causes AVC denials at runtime. Explicitly label the composefs
directory tree as /usr (giving objects usr_t) after the composefs
install completes.

Future work should increase the granularity of SELinux behavior here,
ideally adding composefs-specific types and policy instead of re-using
usr_t.

Closes: #1826
Assisted-by: OpenCode (claude-opus-4-6)
Signed-off-by: John Eckersberg jeckersb@redhat.com

install: Add final SELinux relabel of the physical root filesystem

Perform a full SELinux relabel pass over the physical root filesystem as
the very last step before filesystem finalization. This ensures all files
on the physical root have SELinux labels.

Files that are already labeled (e.g. ostree deployment contents,
composefs objects) are skipped since the relabel only acts on unlabeled
files.

Assisted-by: OpenCode (claude-opus-4-6)
Signed-off-by: John Eckersberg jeckersb@redhat.com

Remove enforcing=0 for sealed composefs

Signed-off-by: John Eckersberg jeckersb@redhat.com

jeckersb · 2026-03-03T01:13:18Z

Assuming this actually works properly (seems to work for me locally but we'll see what the matrix says), we should be able to revert the install parts of #2025, keeping the booted system part as well as the test re-enablement.

gemini-code-assist

Code Review

This pull request introduces a final, comprehensive SELinux relabeling pass on the physical root filesystem just before finalization. This is a robust approach to ensure all files have correct SELinux labels. The logic correctly handles different installation backends by skipping the ostree/deploy directory for ostree-based installs (where its contents are already labeled) and relabeling the entire tree for other scenarios like composefs. The implementation is clean, well-commented, and correctly placed within the installation flow. The changes look solid and improve the reliability of the installation process regarding SELinux contexts.

cgwalters

Isn't the goal here to prove this works by dropping the enforcing=0 in the composefs case? If this does fix it we should of course do that, if it doesn't...I think we should just keep trying until it does right?

cgwalters · 2026-03-03T12:33:03Z

crates/lib/src/install.rs

    }

+    // As the very last step before filesystem finalization, do a full SELinux
+    // relabel of the physical root filesystem.  We skip ostree/deploy because


I think (but there's $details here) we actually need to precisely skip deployment roots not just all of ostree/deploy.

However...can't we also drop the current ostree-only relabeling step with this? That would really prove things out.

Is there a difference in the labeling between ostree-with-composefs vs ostree-without-composefs? In the composefs case I don't think it matters too much how accurate the labels are since the source of truth ends up in the erofs (but does it populate the erofs from the underlying files? I admit I haven't looked too much into that before now...).

But in the non-composefs case (do we even use that anywhere?) the labels are the final labels.

Is there a difference in the labeling between ostree-with-composefs vs ostree-without-composefs? In the composefs case I don't think it matters too much how accurate the labels are since the source of truth ends up in the erofs (but does it populate the erofs from the underlying files? I admit I haven't looked too much into that before now...).

There's not a difference AFAIK no, but a problem is that in the ostree code path we still sometimes for legacy reasons operate directly on a deployment root without the EROFS (running semodule e.g.) and so the labels need to be correct on the underlying files still too.

Anyways though what we're trying to solve here is the labeling of everything else; ostree should be getting labels of the deployment root correct.

jeckersb · 2026-03-03T14:06:54Z

Looks like CI mostly worked, except:

error: Installing to filesystem: Final SELinux relabeling of physical root: No label found in policy 'Some("99a67cf6f12f746505cc0fdc62ddf3ac8fca59ed19f2eb227c17d0667aa68043")' for /sys/fs/cgroup/io.prio.class)

And yes I realized later in the evening after I had walked away from this that I forgot to remove the enforcing=0 bit here 🙄

cgwalters · 2026-03-03T14:12:34Z

/sys/fs/cgroup/io.prio.class

The relabeling code should probably be changed to use https://docs.rs/cap-std-ext/latest/cap_std_ext/dirext/trait.CapStdExtDirExt.html#tymethod.walk with noxdev

jeckersb · 2026-03-03T17:28:29Z

Doesn't seem enough for the files to get just any label, because default_t on the underlying storage is getting denied:

[  178.773356] systemd[1]: Starting ssh-host-keys-migration.service - Update OpenSSH host key permissions...
[  178.774513] audit: type=1400 audit(1772558678.864:100): avc:  denied  { read } for  pid=838 comm="9" path="/39/556cc67f965f16554cb7d0f115a486ad86971eaf7ea804daa445ca3488596f28601a2762ef3115f2bc2ef2faae14e50b1f46f72499a869d561d8209c092b5f" dev="vda3" ino=1064524 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
[  178.777454] systemd[1]: Starting sshd-keygen@ecdsa.service - OpenSSH ecdsa Server Key Generation...
[  178.779754] audit: type=1400 audit(1772558678.868:101): avc:  denied  { read } for  pid=839 comm="9" path="/39/556cc67f965f16554cb7d0f115a486ad86971eaf7ea804daa445ca3488596f28601a2762ef3115f2bc2ef2faae14e50b1f46f72499a869d561d8209c092b5f" dev="vda3" ino=1064524 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
[  178.781967] systemd[1]: Starting sshd-keygen@ed25519.service - OpenSSH ed25519 Server Key Generation...
[  178.785205] audit: type=1400 audit(1772558678.872:102): avc:  denied  { read } for  pid=840 comm="9" path="/39/556cc67f965f16554cb7d0f115a486ad86971eaf7ea804daa445ca3488596f28601a2762ef3115f2bc2ef2faae14e50b1f46f72499a869d561d8209c092b5f" dev="vda3" ino=1064524 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
[  178.787198] systemd[1]: Starting sshd-keygen@rsa.service - OpenSSH rsa Server Key Generation...
[  178.790744] audit: type=1400 audit(1772558678.878:103): avc:  denied  { read } for  pid=841 comm="9" path="/39/556cc67f965f16554cb7d0f115a486ad86971eaf7ea804daa445ca3488596f28601a2762ef3115f2bc2ef2faae14e50b1f46f72499a869d561d8209c092b5f" dev="vda3" ino=1064524 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=file permissive=0
[  178.791656] systemd[1]: sshd-keygen@ecdsa.service: Main process exited, code=exited, status=127/n/a
[  178.797668] systemd[1]: sshd-keygen@ecdsa.service: Failed with result 'exit-code'.

cgwalters · 2026-03-03T19:59:53Z

Ah right I think that's because this code needs to pass an override path of /usr like the ostree one does.

jeckersb · 2026-03-03T20:46:03Z

Circling back to this comment it feels like the most correct approach here would be to label all of the composefs objects with some custom type along with some policy glue (via https://fedoraproject.org/wiki/SELinux/IndependentPolicy ?) to make it function similarly to usr_t. I guess initially we could use usr_t directly although that feels incorrect somehow.

cgwalters · 2026-03-03T20:49:17Z

I agree it'd be better to have a dedicated type for composefs objects. In theory we could ship custom policy addition to add it now without blocking on upstream. There's a variety of examples of this, e.g. https://github.com/cockpit-project/cockpit/tree/main/selinux

I personally would say it seems way easier to just use usr_t and avoid that complexity, but I have no opposition to trying to add it.

jeckersb · 2026-03-06T16:35:41Z

/sys/fs/cgroup/io.prio.class

The relabeling code should probably be changed to use https://docs.rs/cap-std-ext/latest/cap_std_ext/dirext/trait.CapStdExtDirExt.html#tymethod.walk with noxdev

xref for when I inevitably find myself back here in the future looking for it ➡️ #2045

jeckersb · 2026-03-06T20:19:03Z

Ok so coming back to this, I don't think we need to special-case the ostree bits at all, since the bulk relabel will only add a label where the file was previously unlabeled_t. And since the ostree data is already labeled, it's a no-op in there.

The one thing we do need to do though is to explicitly label the composefs data, because that is unlabeled and there's no policy for it, so it ends up as default_t which doesn't work as noted above.

Next pass at this I'm going to:

rebase to pick up lsm: Use walk API with noxdev for recursive SELinux relabeling #2045
drop the part where we skip ostree since it's unnecessary
add code to explicitly re-label the composefs data as /usr for the time being; we can go more into setting up our own custom types and policy in a followup
turn off enforcing=0

That should get us at least closer to the desired end-state. Progress bit by bit 😄

The composefs object store currently has no matching SELinux policy for its storage path, so its contents end up labeled as default_t which causes AVC denials at runtime. Explicitly label the composefs directory tree as /usr (giving objects usr_t) after the composefs install completes. Future work should increase the granularity of SELinux behavior here, ideally adding composefs-specific types and policy instead of re-using usr_t. Closes: bootc-dev#1826 Assisted-by: OpenCode (claude-opus-4-6) Signed-off-by: John Eckersberg <jeckersb@redhat.com>

Perform a full SELinux relabel pass over the physical root filesystem as the very last step before filesystem finalization. This ensures all files on the physical root have SELinux labels. Files that are already labeled (e.g. ostree deployment contents, composefs objects) are skipped since the relabel only acts on unlabeled files. Assisted-by: OpenCode (claude-opus-4-6) Signed-off-by: John Eckersberg <jeckersb@redhat.com>

Signed-off-by: John Eckersberg <jeckersb@redhat.com>

github-actions bot added the area/install Issues related to `bootc install` label Mar 3, 2026

bootc-bot bot requested a review from gursewak1997 March 3, 2026 01:12

gemini-code-assist bot reviewed Mar 3, 2026

View reviewed changes

jeckersb force-pushed the relabel-root branch from fb29b58 to 433159d Compare March 3, 2026 01:16

cgwalters requested changes Mar 3, 2026

View reviewed changes

jeckersb force-pushed the relabel-root branch from 433159d to a2c515d Compare March 6, 2026 21:40

github-actions bot added the area/documentation Updates to the documentation label Mar 6, 2026

jeckersb changed the title ~~install: Add final SELinux relabel of the physical root filesystem~~ Enable enforcing SELinux for sealed images Mar 6, 2026

jeckersb force-pushed the relabel-root branch from a2c515d to a4bd831 Compare March 6, 2026 21:45

Remove enforcing=0 for sealed composefs

959c939

Signed-off-by: John Eckersberg <jeckersb@redhat.com>

jeckersb force-pushed the relabel-root branch from a4bd831 to 959c939 Compare March 6, 2026 22:06

cgwalters approved these changes Mar 6, 2026

View reviewed changes

cgwalters enabled auto-merge (rebase) March 6, 2026 22:20

cgwalters merged commit 86ba489 into bootc-dev:main Mar 7, 2026
46 checks passed

Conversation

jeckersb commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jeckersb commented Mar 3, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

cgwalters left a comment

Choose a reason for hiding this comment

Uh oh!

cgwalters Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

jeckersb Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

cgwalters Mar 3, 2026

Choose a reason for hiding this comment

Uh oh!

jeckersb commented Mar 3, 2026

Uh oh!

cgwalters commented Mar 3, 2026

Uh oh!

jeckersb commented Mar 3, 2026

Uh oh!

cgwalters commented Mar 3, 2026

Uh oh!

jeckersb commented Mar 3, 2026

Uh oh!

cgwalters commented Mar 3, 2026

Uh oh!

jeckersb commented Mar 6, 2026

Uh oh!

jeckersb commented Mar 6, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jeckersb commented Mar 3, 2026 •

edited

Loading

jeckersb commented Mar 3, 2026 •

edited

Loading