Bug 2415016
| Summary: | SELinux denials prevent bwrap thumbnail generation - thumb_t context , missing permissions for namespace and mount operations | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | 0xe14y3 <gridml123> | ||||
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 43 | CC: | adamkis750alt, ashley_paul_12345, ddmpost, dwalsh, f.asot, fry.kun, gridml123, juceda, k.grozdanov, ksenko.lopa, lvrabec, maia, matt.fagnani, mmalik, omosnacek, pkoncity, red, rtweedy, stanley.king, sun.sternness803, vmojzis, zpytela | ||||
| Target Milestone: | --- | Keywords: | Desktop | ||||
| Target Release: | --- | ||||||
| Hardware: | x86_64 | ||||||
| OS: | Linux | ||||||
| URL: | https://bugzilla.redhat.com/show_bug.cgi?id=2327872 | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | selinux-policy-42.17-1.fc43 | Doc Type: | --- | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2025-11-29 16:48:27 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
Created attachment 2114379 [details]
Comprehensive SELinux policy module for bwrap thumbnail generation (thumb_t context)
This policy module adds all necessary permissions for bwrap to function
properly in the thumb_t context for thumbnail generation. It addresses
user_namespace creation, filesystem mount operations, and symlink creation
that are required for bwrap's sandboxing mechanism.
The policy has been tested on Fedora 43 with XFCE/Tumbler and resolves the
progressive denials that appear during thumbnail generation.
Amazing, I used your proposed changes including comments. Please review if the attribution is correct: https://github.com/fedora-selinux/selinux-policy/pull/2950 You can also try the copr build attached to the PR. Still, I'd like to ask about: # 7. SYMBOLIC LINK CREATION # Allows bwrap to create stdin/stdout/stderr symlinks in sandbox tmpfs allow thumb_t thumb_tmpfs_t:lnk_file create; is it only the create permission? and # Mount on tmpfs directories (for /tmp isolation) allow thumb_t tmpfs_t:dir mounton; is this required when thumb_t uses its private thumb_tmpfs_t type? Thank you so much for the quick response and for creating the PR! I'm
really honored to contribute to Fedora - this is actually my first time
contributing to an open-source project!
I've reviewed the PR and the attribution looks perfect. Thank you for
including me!
Regarding your questions:
Question 1: Symbolic Link Permissions
Based on what I can see in my audit logs, the only denials I'm getting are
for create:
type=AVC msg=audit(...): avc: denied { create } for pid=44383 comm="bwrap"
name="stdin" scontext=...thumb_t... tcontext=...thumb_tmpfs_t...
tclass=lnk_file permissive=0
I'm not seeing denials for read, write, or unlink in my logs, but
I'm still fairly new to SELinux so I'm not 100% certain if that means
they're not needed, or if maybe those operations just aren't being
triggered in my specific use case. From what I can observe, it seems like
bwrap only needs to create the symlinks, but I could be missing something!
Question 2: tmpfs_t vs thumb_tmpfs_t
From what I can see in my logs, yes, both seem to be needed:
First, I see bwrap mounting on the generic tmpfs_t:
type=AVC msg=audit(...): avc: denied { mount } for pid=40364 comm="bwrap"
name="/" dev="tmpfs" ino=1 scontext=...thumb_t...
tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=0
Then later, it mounts on directories labeled thumb_tmpfs_t:
type=AVC msg=audit(...): avc: denied { mounton } for pid=42076
comm="bwrap"
path="/tmp/newroot" dev="tmpfs" ino=2 scontext=...thumb_t...
tcontext=...thumb_tmpfs_t... tclass=dir permissive=0
My understanding (though I could be wrong) is that bwrap creates the tmpfs
first, which gets the generic tmpfs_t label, and then directories
within it get transitioned to thumb_tmpfs_t. So it seems like both are
needed for the process to work, but I'm still learning how type
transitions work, so please correct me if I'm misunderstanding!
Testing
I'd be happy to test the copr build!
Thank you again for your patience and for helping me learn. I really
appreciate you taking the time to explain!
Going to merge the pr today so that we have a new build this week. *** Bug 2408907 has been marked as a duplicate of this bug. *** *** Bug 2416997 has been marked as a duplicate of this bug. *** FEDORA-2025-b330880341 (selinux-policy-42.17-1.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2025-b330880341 FEDORA-2025-b330880341 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2025-b330880341` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2025-b330880341 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. *** Bug 2417501 has been marked as a duplicate of this bug. *** *** Bug 2417713 has been marked as a duplicate of this bug. *** FEDORA-2025-b330880341 (selinux-policy-42.17-1.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report. The following AVCs still happen with:
selinux-policy-0:42.17-1.fc43.noarch
selinux-policy-minimum-0:42.17-1.fc43.noarch
selinux-policy-targeted-0:42.17-1.fc43.noarch
time->Sat Nov 29 23:28:14 2025
type=AVC msg=audit(1764455294.584:2804): avc: denied { mounton } for pid=457165 comm="bwrap" path="/tmp" dev="tmpfs" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=1
----
time->Sat Nov 29 23:28:14 2025
type=AVC msg=audit(1764455294.584:2805): avc: denied { mount } for pid=457165 comm="bwrap" name="/" dev="tmpfs" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Sat Nov 29 23:28:14 2025
type=AVC msg=audit(1764455294.585:2806): avc: denied { mount } for pid=457165 comm="bwrap" name="/" dev="devpts" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=filesystem permissive=1
----
time->Sat Nov 29 23:28:14 2025
type=AVC msg=audit(1764455294.586:2807): avc: denied { unmount } for pid=457165 comm="bwrap" scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Sat Nov 29 23:28:16 2025
type=AVC msg=audit(1764455296.205:2809): avc: denied { mount } for pid=457441 comm="bwrap" name="/" dev="tmpfs" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Sat Nov 29 23:28:16 2025
type=AVC msg=audit(1764455296.207:2810): avc: denied { unmount } for pid=457441 comm="bwrap" scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmpfs_t:s0 tclass=filesystem permissive=1
----
time->Sat Nov 29 23:28:16 2025
type=AVC msg=audit(1764455296.611:2812): avc: denied { mounton } for pid=457486 comm="bwrap" path="/tmp" dev="tmpfs" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=1
----
time->Sat Nov 29 23:28:16 2025
type=AVC msg=audit(1764455296.614:2813): avc: denied { mount } for pid=457486 comm="bwrap" name="/" dev="devpts" ino=1 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:devpts_t:s0 tclass=filesystem permissive=1
note: tested under mate-desktop. Also, the following may be related:
Then si dovrebbe segnalare il problema come bug.
È possibile generare un modulo di politica locale per consentire questo accesso.
Do
consentire questo accesso per ora eseguendo:
# ausearch -c 'blocking-2' --raw | audit2allow -M my-$MODULE_NOME
# semodule -X 300 -i mio-blocking2.pp
Additional Information:
Source Context unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023
Target Context system_u:system_r:systemd_machined_t:s0
Target Objects /run/systemd/userdb/io.systemd.Machine [
unix_stream_socket ]
Source blocking-2
Source Path blocking-2
Port <Sconosciuto>
Host (removed)
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-42.17-1.fc43.noarch
Local Policy RPM selinux-policy-targeted-42.17-1.fc43.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Permissive
Host Name (removed)
Platform Linux (removed) 6.17.8-300.fc43.x86_64 #1 SMP
PREEMPT_DYNAMIC Fri Nov 14 01:47:12 UTC 2025
x86_64
Alert Count 4
First Seen 2025-11-29 23:28:13 CET
Last Seen 2025-11-29 23:31:12 CET
Local ID 121e8f80-08c1-400f-b4af-3956db94199a
Raw Audit Messages
type=AVC msg=audit(1764455472.151:2827): avc: denied { connectto } for pid=461507 comm="blocking-3" path="/run/systemd/userdb/io.systemd.Machine" scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:system_r:systemd_machined_t:s0 tclass=unix_stream_socket permissive=1
Hash: blocking-2,thumb_t,systemd_machined_t,unix_stream_socket,connectto
*** Bug 2417868 has been marked as a duplicate of this bug. *** *** Bug 2418001 has been marked as a duplicate of this bug. *** *** Bug 2418045 has been marked as a duplicate of this bug. *** *** Bug 2418292 has been marked as a duplicate of this bug. *** *** Bug 2418072 has been marked as a duplicate of this bug. *** *** Bug 2418584 has been marked as a duplicate of this bug. *** *** Bug 2419551 has been marked as a duplicate of this bug. *** *** Bug 2419969 has been marked as a duplicate of this bug. *** *** Bug 2425217 has been marked as a duplicate of this bug. *** (In reply to Fedora Update System from comment #11) > FEDORA-2025-b330880341 (selinux-policy-42.17-1.fc43) has been pushed to the > Fedora 43 stable repository. > If problem still persists, please make note of it in this bug report. Still getting these errors with selinux-policy 42.22-1.fc43: type=AVC msg=audit(1770158815.189:1488): avc: denied { mounton } for pid=766375 comm="bwrap" path="/newroot/usr/lib/fontconfig/cache" dev="dm-0" ino=13817 scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fonts_cache_t:s0 tclass=dir permissive=0 OK, this is a new one, adding to another commit. |
When taking screenshots or viewing images in the file manager (Thunar/GNOME Files), thumbnails fail to generate. Instead, orange placeholder icons appear. SELinux continuously generates alerts about bwrap being denied various operations. Thumbnail services (Tumbler/GNOME Desktop Thumbnailer) use bwrap (bubblewrap) to generate thumbnails in a secure sandbox. The current SELinux policy for the thumb_t context lacks necessary permissions for bwrap's sandboxing operations. Reproducible: Always Steps to Reproduce: 1.Install Fedora 43 with default SELinux enforcing mode 2.Install XFCE desktop (or use GNOME) 3.Take a screenshot using screenshot tool (Print Screen) 4.navigate to Pictures folder in file manager (Thunar or GNOME Files) 5.Observe thumbnails and SELinux alerts Actual Results: - Thumbnails show as orange placeholder icons instead of actual image previews - SELinux alert notifications appear repeatedly - Multiple SELinux denials in logs (journalctl -xe | grep selinux): Denial 1 - User Namespace Creation: type=AVC avc: denied { create } comm="bwrap" tclass=user_namespace Denial 2 - Mount Operations: type=AVC avc: denied { mounton } comm="bwrap" path="/tmp/newroot" tclass=dir Denial 3 - Filesystem Remount: type=AVC avc: denied { remount } comm="bwrap" tclass=filesystem Denial 4 - Symbolic Link Creation: type=AVC avc: denied { create } comm="bwrap" name="stdin" tclass=lnk_file All denials show: scontext=unconfined_u:unconfined_r:thumb_t:s0-s0:c0.c1023 tcontext varies by operation Expected Results: - Thumbnails should generate successfully showing actual image previews - No SELinux denials during thumbnail generation - Thumbnail previews appear immediately in file manager without orange placeholders Additional Information: - Thumbnails should generate successfully showing actual image previews - No SELinux denials during thumbnail generation - Thumbnail previews appear immediately in file manager without orange placeholders Additional Information I've attempted to fix this issue multiple times by progressively adding permissions as new denials appeared: 1. First attempt: Added mounton permissions → New remount denial appeared 2. Second attempt: Added remount permission → New user_namespace denial appeared 3. Third attempt: Added user_namespace permission → New lnk_file denial appeared 4. Current attempt: Added lnk_file permission → Still seeing issues This whack-a-mole pattern suggests bwrap requires a comprehensive set of permissions. PROPOSED SOLUTION - SELinux Policy Module: I've created a policy module that adds these permissions to thumb_t: 1. User namespace creation: allow thumb_t self:user_namespace create; 2. Filesystem operations: allow thumb_t fs_t:filesystem { mount remount unmount }; 3. Mount points: allow thumb_t root_t:dir mounton; allow thumb_t thumb_tmpfs_t:dir mounton; allow thumb_t tmpfs_t:dir mounton; 4. Symlink creation: allow thumb_t thumb_tmpfs_t:lnk_file create; 5. Capabilities: allow thumb_t self:cap_userns { net_admin setpcap sys_admin sys_ptrace }; 6. Process caps: allow thumb_t self:process setcap; 7. Network config: allow thumb_t self:netlink_route_socket nlmsg_write; All permissions are legitimate requirements for bwrap's sandboxing operations. WORKAROUND: Users can temporarily fix with: sudo ausearch -c 'bwrap' --raw | sudo audit2allow -M my-bwrap && sudo semodule -i my-bwrap.pp I can attach the complete .te policy file if needed. As a new Linux user, I apologize if I've missed anything. Please let me know if you need more information. Thank you!