Bug 2220643
| Summary: | selinux policy logs denys read/write when running sa-update from spamassassin | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | William Taylor <williamt> |
| Component: | selinux-policy | Assignee: | Nobody <nobody> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | apeetham, lvrabec, mmalik, zpytela |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
| Hardware: | Unspecified | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-38.1.18-1.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2023-11-07 08:52:30 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Deadline: | 2023-07-18 | ||
Hi William, Can you reproduce the issue in permissive mode with full auditing enabled? setenforce 0 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today Thank you I believe we do not need any additional information as the problem was troubleshooted in bz#2216408, so it's needed to backport d2fdbe5ca Allow sa-update manage spamc home files and while there also fb09f6985 Allow sa-update connect to systemlog services Thank you Zdenko *** Bug 2208349 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2023:6617 |
When running sa-update out of cron.daily, selinux logs these denies in the audit.log node=localhost type=AVC msg=audit(1688552528.749:332239): avc: denied { write } for pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0 node=localhost type=AVC msg=audit(1688552530.625:332242): avc: denied { read } for pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0 node=localhost type=AVC msg=audit(1688552530.625:332243): avc: denied { write } for pid=63266 comm="sa-update" name=".spamassassin" dev="md1" ino=116198 scontext=system_u:system_r:spamd_update_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:spamc_home_t:s0 tclass=dir permissive=0 inode 116198 is /root/.spamassassin # ls -lZ /root/.spamassassin -rw-rw-r--. root root system_u:object_r:spamc_home_t:s0 user_prefs In a previous bug (864501) user Scott said "The code that causes this is in /usr/bin/sa-update calling the function lint_check_dir() when the downloaded spam rules are checked for correctness. A instance of Mail::SpamAssassin is created, and lint_rules() is called on it, which calls init(1) (use_user_pref=1) in turn calling get_and_create_userstate_dir(), which stats $self->{user_dir}, ".spamassassin") looking for a user pref." This use_user_prefs is basically hard coded even though SpamAssassin::init takes use_user_prefs as an argument it does this a few lines down. #fix spamd reading root prefs file if (!defined $use_user_pref) { $use_user_pref = 1; } Not sure if this is some sort of hack that got left in place or what but it essentially makes it so it always tries to use user prefs. I'm don't know if I have something misconfigured or if this is an actual bug. Either spamassassin shouldn't be forced to use user prefs when running sa-update OR read/write should be added to the policy. My audit2allow wants me to add this: allow spamd_update_t spamc_home_t:dir { read write }; This is what is in the current policy: # grep 'allow spamd_update_t spamc_home_t' spamassassin.cil (allow spamd_update_t spamc_home_t (dir (getattr open search))) (allow spamd_update_t spamc_home_t (dir (getattr open search))) Running the latest version 4.0 of spamassassin.