Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Radicale allows to configure hooks, which is e.g. used for implementing versioning with git. The installed configuration file and the official documentation contain a git hook example. Thus, arguably, a user is quite tempted to actually use this feature. Version-Release number of selected component (if applicable): python3-radicale3-3.0.6-13.fc33.noarch How reproducible: always Steps to Reproduce: 1. sudo -u radicale git init /var/lib/radicale/collections 2. add to /etc/radicale/config, under `[storage]`: hook = git add -A && (git diff --cached --quiet || git commit -m "Changes by "%(user)s) 3. journalctl -f 4. trigger some change in a cal/carddav client Actual results: audit[37230]: AVC avc: denied { setpgid } for pid=37230 comm="radicale" scontext=system_u:system_r:radicale_t:s0 tcontext=system_u:system_r:radicale_t:s0 tclass=process permissive=0 radicale[36804]: [2021-02-15 20:02:41 +0100] [36804/Thread-24] [ERROR] An exception occurred during PUT request on '/juser/dead-cafe-2323.ics': Exception occurred in preexec_fn. And the client displays a sync error. Expected results: No such AVC error. Additional info:
I have no chance to simulate this currently, can you please change to SELinux permissive mode, because potentially the displayed AVC message is not the only one. # setenforce 0 Once SELinux permissive mode is active and external plugin execution was successful, please post # grep radicale /var/log/audit/audit.log | audit2allow -m radicale after review I can create a new test RPM with extended radicale.te - if not simply be enabled by setsebool (audit2allow output will show hint)
Hm, I don't think that the audit2allow output is too useful in this case since it looks to broad. For example, it also includes execute_no_trans: module radicale 1.0; require { type radicale_var_lib_t; type radicale_t; type radicalehook_exec_t; class process setpgid; class file { execute execute_no_trans getattr ioctl map open read }; } #============= radicale_t ============== #!!!! This avc can be allowed using the boolean 'domain_can_mmap_files' allow radicale_t radicale_var_lib_t:file map; allow radicale_t radicalehook_exec_t:file { execute execute_no_trans getattr ioctl open read }; allow radicale_t self:process setpgid; So I moved the hook shell command to /usr/local/bin/radicale-change-hook.sh for easier testing. And I labeled that script as radicalehook_exec_t. Note that another hook script or command might be labeled completely different such that second last line wouldn't match. What's perhaps more more appropriate here is to work with a domain transition for the hook. Under this approach I'll end up with the following: allow radicale_t self:process setpgid; radicalehook_domtrans(radicale_t) auth_use_nsswitch(radicalehook_t) corecmd_exec_shell(radicalehook_t) corecmd_exec_bin(radicalehook_t) manage_dirs_pattern(radicalehook_t, radicale_var_lib_t, radicale_var_lib_t) manage_files_pattern(radicalehook_t, radicale_var_lib_t, radicale_var_lib_t) manage_lnk_files_pattern(radicalehook_t, radicale_var_lib_t, radicale_var_lib_t) allow radicalehook_t radicale_var_lib_t:file map; In addition to the boilerplate generated by: sepolicy generate --application /usr/local/bin/radicale-change-hook.sh -n radicalehook
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Is it possible to add that kind of SElinux policy extension with a toogle and being off by default? Found no example so far how to manage that in custom policy extension (having e.g. a new SEbool like "radicale_hook")
I don't have experience with adding SELinux toggles, but it sounds like it should be possible. However, I don't know if it's worth it, though. I mean if you choose some fixed hook script location for relabeling, then the new rules aren't effective unless somebody actively places a hook script there (and relabels it). FWIW, my current addon policy for my git hook script is available on github: https://github.com/gsauthof/playbook/tree/master/server/roles/radicale/files/selinux The hook script is also available: https://github.com/gsauthof/playbook/blob/master/server/roles/radicale/files/radicale-change-hook.sh
Sounds like a generic solution is not easy to implement, can we postpone work on it until more than one run into similar issue?
Yes, we can do that. On the one hand, since the radicale documentation details how to write a git commit hook, people should expect that it's supported, out-of-the-box. And since Fedora has SELinux enabled, by default, it should be expected that is also works with SELinux enabled. On the other hand, I have the feeling that 99 % of the Fedora users and developers are running Fedora with SELinux disabled, and not all radicale users are interested in commit hooks. IOW, the intersection of Fedora users, Radicale users, users who keep SELinux enableand Radicale hook users is perhaps very small. When you postpone, can you add a comment to the packaged `/etc/radicale/config` with a short note that the SELinux policy currently not covering hooks and a link to this bug?
Notes added to subpackage description and default config by: https://src.fedoraproject.org/rpms/radicale/c/3f3d2ea656f0116cb35ffe0a80a89039779d02b5?branch=f35
FEDORA-2021-8bfea0c937 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2021-8bfea0c937
FEDORA-2021-8bfea0c937 has been pushed to the Fedora 35 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-8bfea0c937` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-8bfea0c937 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2021-8bfea0c937 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-b8ffe9d03d (radicale-3.3.1-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-b8ffe9d03d
FEDORA-2024-b8ffe9d03d (radicale-3.3.1-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-54d99da1a6 (radicale-3.3.1-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-54d99da1a6
FEDORA-2024-e60a6b12a0 (radicale-3.3.1-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-e60a6b12a0
FEDORA-2024-5f452dbb76 (radicale-3.3.1-1.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f452dbb76
FEDORA-EPEL-2024-70340515ea (radicale-3.3.1-1.el9) has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-70340515ea
FEDORA-EPEL-2024-786aa740a9 (radicale-3.3.1-1.el8) has been submitted as an update to Fedora EPEL 8. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-786aa740a9
FEDORA-2024-e60a6b12a0 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-e60a6b12a0` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-e60a6b12a0 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-54d99da1a6 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-54d99da1a6` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-54d99da1a6 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-786aa740a9 has been pushed to the Fedora EPEL 8 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-786aa740a9 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2024-70340515ea has been pushed to the Fedora EPEL 9 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2024-70340515ea See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-5f452dbb76 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-5f452dbb76` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-5f452dbb76 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-e60a6b12a0 (radicale-3.3.1-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-54d99da1a6 (radicale-3.3.1-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2024-70340515ea (radicale-3.3.1-1.el9) has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2024-786aa740a9 (radicale-3.3.1-1.el8) has been pushed to the Fedora EPEL 8 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2025-8ab77fbc65 (radicale-3.4.0-2.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2025-8ab77fbc65
FEDORA-2025-8ab77fbc65 (radicale-3.4.0-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.