Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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.
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
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.