Description of problem: flatpak update SELinux is preventing pool-/usr/libex from 'getattr' accesses on the lnk_file /var/lib/flatpak/app/org.signal.Signal/x86_64/stable/active. ***** Plugin catchall_labels (83.8 confidence) suggests ******************* If you want to allow libex to have getattr access on the active lnk_file Then you need to change the label on /var/lib/flatpak/app/org.signal.Signal/x86_64/stable/active Do # semanage fcontext -a -t FILE_TYPE '/var/lib/flatpak/app/org.signal.Signal/x86_64/stable/active' where FILE_TYPE is one of the following: admin_home_t, bin_t, boot_t, device_t, etc_runtime_t, etc_t, fonts_cache_t, fonts_t, ld_so_t, lib_t, locale_t, man_cache_t, man_t, proc_t, root_t, rpm_script_tmp_t, security_t, shell_exec_t, src_t, system_conf_t, system_db_t, system_dbusd_var_lib_t, textrel_shlib_t, tmp_t, usr_t, var_run_t, var_t. Then execute: restorecon -v '/var/lib/flatpak/app/org.signal.Signal/x86_64/stable/active' ***** Plugin catchall (17.1 confidence) suggests ************************** If you believe that libex should be allowed getattr access on the active lnk_file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'pool-/usr/libex' --raw | audit2allow -M my-poolusrlibex # semodule -X 300 -i my-poolusrlibex.pp Additional Information: Source Context system_u:system_r:flatpak_helper_t:s0 Target Context system_u:object_r:var_lib_t:s0 Target Objects /var/lib/flatpak/app/org.signal.Signal/x86_64/stab le/active [ lnk_file ] Source pool-/usr/libex Source Path pool-/usr/libex Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-36.5-1.fc36.noarch Local Policy RPM flatpak-selinux-1.12.7-1.fc36.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.16.16-200.fc35.x86_64 #1 SMP PREEMPT Wed Mar 23 00:44:58 CET 2022 x86_64 x86_64 Alert Count 4 First Seen 2022-03-31 23:27:54 CEST Last Seen 2022-04-02 10:39:45 CEST Local ID e6ca35c8-7e82-4aad-ba28-80766ffe0d00 Raw Audit Messages type=AVC msg=audit(1648888785.624:450): avc: denied { getattr } for pid=4980 comm="pool-/usr/libex" path="/var/lib/flatpak/app/org.signal.Signal/x86_64/stable/active" dev="nvme0n1p3" ino=4980655 scontext=system_u:system_r:flatpak_helper_t:s0 tcontext=system_u:object_r:var_lib_t:s0 tclass=lnk_file permissive=0 Hash: pool-/usr/libex,flatpak_helper_t,var_lib_t,lnk_file,getattr Version-Release number of selected component: selinux-policy-targeted-36.5-1.fc36.noarch Additional info: component: flatpak reporter: libreport-2.17.1 hashmarkername: setroubleshoot kernel: 5.16.16-200.fc35.x86_64 type: libreport
There are also reports of missing 'map' access: type=AVC msg=audit(16.04.2022 13:29:45.311:223) : avc: denied { map } for pid=1038 comm=gnome-session-b path=/var/lib/flatpak/exports/share/mime/mime.cache dev="nvme0n1p3" ino=34290936 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file ---- type=AVC msg=audit(16.04.2022 13:29:46.748:232) : avc: denied { map } for pid=1049 comm=gnome-shell path=/var/lib/flatpak/exports/share/icons/hicolor/icon-theme.cache dev="nvme0n1p3" ino=34290938 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:object_r:var_lib_t:s0 tclass=file
Are files_getattr_var_lib_dirs and files_map_var_lib_files the appropriate interfaces to allow 'getattr' and 'map' inside /var/lib/flatpak?
It'd be better to add one permission and retest, or switch the system to SELinux permissive as I suppose getattr is not enough, so I'd go with files_read_var_lib_symlinks() for the denial reported in #c0. The #c1 denials are addressed in selinux-policy.
After following your pointers in: https://bugzilla.redhat.com/show_bug.cgi?id=2072274#c2 ... I see that 'files_read_var_lib_files' evaluates to: interface(`files_read_var_lib_files',` gen_require(` type var_t, var_lib_t; ') allow $1 var_lib_t:dir { getattr search open read lock ioctl }; // read_files_pattern allow $1 { var_t var_lib_t }:dir { getattr search open }; allow $1 var_lib_t:file { open getattr read ioctl lock }; ') ... and 'files_read_var_lib_symlinks' evaluates to: interface(`files_read_var_lib_symlinks',` gen_require(` type var_t, var_lib_t; ') // read_lnk_files_pattern allow $1 { var_t var_lib_t }:dir { getattr search open }; allow $1 var_lib_t:lnk_file { getattr read }; ') This makes me wonder if permissions granted to file:s automatically cover lnk_file:s, or if they have to be mentioned separately. I ended up looking at: https://selinuxproject.org/page/ObjectClassesPerms ... but it doesn't clearly specify that (and the page looks old because it doesn't mention the 'map' and 'watch' permissions). (What's a good URL or reference to read up on SELinux? I get a bit lost searching around on the Internet - it's possible that I am not using the right keywords. Sometimes I end up reading: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/index Is there anything else you would recommend?)
> This makes me wonder if permissions granted to file:s automatically > cover lnk_file:s, or if they have to be mentioned separately. I see that we had added files_read_var_lib_files() in bug 2070741 in response to 'read' accesses to a 'lnk_file' being denied, and that seems to have worked. This makes me think that files_read_var_lib_files() will also allow 'getattr' accesses to lnk_file:s and we don't need to do anything here.
(In reply to Debarshi Ray from comment #4) > This makes me wonder if permissions granted to file:s automatically cover > lnk_file:s, or if they have to be mentioned separately. I ended up looking > at: > https://selinuxproject.org/page/ObjectClassesPerms > > ... but it doesn't clearly specify that (and the page looks old because it > doesn't mention the 'map' and 'watch' permissions). The file and lnk_file are distinct classes so different rules apply. Some interfaces allow also symlinks rules. Updated information, though still very brief, can be found here: https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/flask/flask_documentation.md > > (What's a good URL or reference to read up on SELinux? I get a bit lost > searching around on the Internet - it's possible that I am not using the > right keywords. Sometimes I end up reading: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ > html/using_selinux/index > > Is there anything else you would recommend?) RHEL documentation is good and continuously being worked on, but there are different resources serving different purposes. https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/ https://selinuxproject.org/page/Category:Notebook
(In reply to Zdenek Pytela from comment #6) > (In reply to Debarshi Ray from comment #4) > > This makes me wonder if permissions granted to file:s automatically cover > > lnk_file:s, or if they have to be mentioned separately. I ended up looking > > at: > > https://selinuxproject.org/page/ObjectClassesPerms > > > > ... but it doesn't clearly specify that (and the page looks old because it > > doesn't mention the 'map' and 'watch' permissions). > > The file and lnk_file are distinct classes so different rules apply. Some > interfaces allow also symlinks rules. > Updated information, though still very brief, can be found here: > https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/flask/ > flask_documentation.md Umm... ok, but I am still confused. :) Do we need files_read_var_lib_symlinks() for this denial? Or is files_read_var_lib_files() enough? > > (What's a good URL or reference to read up on SELinux? I get a bit lost > > searching around on the Internet - it's possible that I am not using the > > right keywords. Sometimes I end up reading: > > > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/ > > html/using_selinux/index > > > > Is there anything else you would recommend?) > > RHEL documentation is good and continuously being worked on, but there are > different resources serving different purposes. > https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-selinux/ > https://selinuxproject.org/page/Category:Notebook Thanks for the pointers!
(In reply to Debarshi Ray from comment #7) > (In reply to Zdenek Pytela from comment #6) > > (In reply to Debarshi Ray from comment #4) > > > This makes me wonder if permissions granted to file:s automatically cover > > > lnk_file:s, or if they have to be mentioned separately. I ended up looking > > > at: > > > https://selinuxproject.org/page/ObjectClassesPerms > > > > > > ... but it doesn't clearly specify that (and the page looks old because it > > > doesn't mention the 'map' and 'watch' permissions). > > > > The file and lnk_file are distinct classes so different rules apply. Some > > interfaces allow also symlinks rules. > > Updated information, though still very brief, can be found here: > > https://github.com/fedora-selinux/selinux-policy/blob/rawhide/policy/flask/ > > flask_documentation.md > > Umm... ok, but I am still confused. :) > > Do we need files_read_var_lib_symlinks() for this denial? Or is > files_read_var_lib_files() enough? files_read_var_lib_files() does not contain any rule for the lnk_file class, so files_read_var_lib_symlinks() is needed, too.
Does this look good to you: https://github.com/flatpak/flatpak/pull/4992 ?
FEDORA-2022-44170a0443 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-44170a0443
FEDORA-2022-44170a0443 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-44170a0443` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-44170a0443 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-44170a0443 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.