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!
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. ***