Description of problem: It uppears the spamassassin update process tries to run "pgrep", but is denied access to the /proc/<pid> directories in many cases. The target context varies with each process, so I got many of these. I attach an example for httpd_t. Source Context system_u:system_r:spamd_update_t:SystemLow Target Context system_u:system_r:httpd_t:SystemLow Target Objects /proc/<pid> [ dir ] Source pgrep Source Path pgrep Port <Unknown> Host mimmi Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-37.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name mimmi Platform Linux mimmi 5.0.13-300.fc30.x86_64 #1 SMP Mon May 6 00:39:45 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-05-20 00:00:01 CEST Last Seen 2019-05-20 00:00:01 CEST Local ID 744f27f3-d25b-46b9-8be3-515a3b2a9614 Raw Audit Messages type=AVC msg=audit(1558303201.547:119623): avc: denied { getattr } for pid=4655 comm="pgrep" path="/proc/968" dev="proc" ino=12073245 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:system_r:httpd_t:s0 tclass=dir permissive=0 Hash: pgrep,spamd_update_t,httpd_t,dir,getattr Version-Release number of selected component (if applicable): selinux-policy-targeted-3.14.3-37.fc30.noarch Additional info: This started the night after I upgraded to this policy, which made the bug 1705331 go away. I'm guessing the execution of that bug was now allowed, which resulted in triggering these error during execution. Checking the /usr/share/spamassassin/sa-update.cron script, it seems it uses "pgrep" to find out if any of a number of interesting daemons is running.
Created attachment 1571512 [details] AVCs when running in permissive mode Looking once more at the update script, I realised it would give up because of the AVCs and not try to do anything. In order to catch any additional AVCs that would be triggered, I made the spamd_update_t domain permissive. After last night's run, there were indeed additional reports. Most of them were about search/open/read access in the /proc filesystem. There was also one about failing execute_no_trans on the sa-update script, and one when trying to open the sa-update.log file. For reference, I attach the complete output from ausearch -m avc -se spamd_update_t -ts today
commit 9c3b5d3308f713cb66554ab3d85cffd73861c6fc (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Tue May 21 15:39:13 2019 +0200 Dontaudit spamd_update_t domain to read all domains states BZ(1711799)
Will it help to just "dontaudit" them? Will not that mean that the "pgrep" command in the upgrade script fails, and no update happen? I thought these accesses would have to be allowed for the script to work. At least for the domains the relevant servers run in, like "spamd_t" in my case. https://src.fedoraproject.org/rpms/spamassassin/blob/master/f/sa-update.cronscript#_12
*** Bug 1712652 has been marked as a duplicate of this bug. ***
FEDORA-2019-3f20be4d52 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f20be4d52
selinux-policy-3.14.3-38.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-3f20be4d52
selinux-policy-3.14.3-38.fc30 only hides the symptoms; it doesn't solve the problem. The sa-update.cron script needs to be allowed to run pgrep or it will give up without doing anything at all. I'm trying to make a local module that will allow the updates. This is what I have so far. allow spamd_update_t domain:dir { getattr search }; allow spamd_update_t domain:file { open read }; allow spamd_update_t spamd_update_exec_t:file execute_no_trans; allow spamd_update_t var_log_t:file open; systemd_exec_systemctl(spamd_update_t)
Hi Goran, Does your workadounds works? Thanks, Lukas.
I should have mentioned: I had to add two allow rules to allow it to restart the service too. After updating the spam database, the cron job also does a condrestart on spamassassin and a few other services. My current version looks as shown below. With this module loaded, everything works as far as I can tell. ======================================= module sa-updatefix 1.4; require { type init_t; type spamd_update_t; type spamd_update_exec_t; type systemd_unit_file_t; type var_log_t; attribute domain; all_kernel_class_perms } allow spamd_update_t domain:dir { getattr search }; allow spamd_update_t domain:file { open read }; allow spamd_update_t spamd_update_exec_t:file execute_no_trans; allow spamd_update_t var_log_t:{ dir file } open; systemd_exec_systemctl(spamd_update_t) allow spamd_update_t init_t:system status; allow spamd_update_t systemd_unit_file_t:service { start status };
FEDORA-2019-9da5c35472 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9da5c35472
Hi Goran, I fixed first three rules from your policy. commit a7b705c33596e796d7776030acc5328612de9b46 (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Tue Jun 18 13:39:25 2019 +0200 Allow spamd_update_t domain to read state of other domains and can execute itself For rest of them I need raw AVC msgs, could you please provide it? Thanks, Lukas.
Created attachment 1581850 [details] AVCs without the last four rules I commented out the last four (non-empty) lines of my module, and made spamd_update_t a permissive domain. Then I triggered another run of sa-update, and got the attached AVCs. Was that what you wanted? In case it matters, I made an attempt to check that it makes sense. It seems so to me. There was no open on a var_log_t DIRECTORY, which is reasonable since the log file existed now. It is rotated monthly, so that permission will only be needed occasionally. The two AVCs for comm=systemctl I guess was allowed by systemd_exec_systemctl(), presumably by allowing the transition into systemd_systemctl_t. The remaining ones are the ones I explicitly allow.
selinux-policy-3.14.3-39.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9da5c35472
selinux-policy-3.14.3-39.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
As I suspected in comment 3, this doesn't work. I don't get any AVC alerts, but the sa-update.cron script still fails. More precisely, it will give up since none of its attempts to "pgrep" for a mail filtering process succeeds. It believes there isn't any running and stops, but the real reason is that SELinux prevents the discovery. If I disable dontaudit, I see the pgrep AVCs from my first attachment again. (In enforcing mode, it doesn't get further than that.)
Hi Goran, Could you please test following scratch build? https://copr-be.cloud.fedoraproject.org/results/lvrabec/selinux-policy-nightly/fedora-30-x86_64/00954967-selinux-policy/ Thanks, Lukas.
Hi Lukas, Now I'm back and have tried 3.14.4-5.fc30.12. That version seems to work better. Running the sa-update systemd service now successfully updates the database, and restarts spamd.
Perfect. THanks for testing. Fix will be part of new selinux-policy rpm package update.
FEDORA-2019-9c513c4cf8 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9c513c4cf8
selinux-policy-3.14.3-40.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9c513c4cf8
With 3.14.3-40.fc30 the updating itself works, but not the logging nor the restart of the service afterwards. With 3.14.4-5.fc30.12 these parts too worked. (Do you want a new bugzilla about the remaining parts, or will it show up in the next update anyway?) time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.289:559733): avc: denied { open } for pid=16393 comm="sa-update.cron" path="/var/log/sa-update.log" dev="dm-0" ino=5111911 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.289:559734): avc: denied { open } for pid=16393 comm="sa-update.cron" path="/var/log/sa-update.log" dev="dm-0" ino=5111911 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:var_log_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.289:559735): avc: denied { getattr } for pid=16393 comm="sa-update.cron" path="/usr/bin/systemctl" dev="dm-0" ino=117313184 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.741:559736): avc: denied { execute } for pid=23707 comm="service" name="systemctl" dev="dm-0" ino=117313184 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.741:559737): avc: denied { getattr } for pid=23707 comm="service" path="/usr/bin/systemctl" dev="dm-0" ino=117313184 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.741:559738): avc: denied { getattr } for pid=23707 comm="service" path="/usr/bin/systemctl" dev="dm-0" ino=117313184 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 ---- time->Thu Jul 11 13:07:04 2019 type=AVC msg=audit(1562843224.742:559739): avc: denied { getattr } for pid=23707 comm="service" path="/usr/bin/systemctl" dev="dm-0" ino=117313184 scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0
selinux-policy-3.14.3-40.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
Not fully resolved yet as indicated above, so I reopen. (Let me know if you prefer a separate bugzilla for the remaining problems.)
FEDORA-2019-b156bd756a has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-b156bd756a
selinux-policy-3.14.3-41.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-b156bd756a
The log is written with 3.14.3-41.fc30. Looking at the execution in detail, it seems there is still one more detail missing: the spamassassin service doesn't get restarted after an update. There are USER_AVCs which I failed to list in comment 21, sorry for that. time->Sat Jul 20 15:34:43 2019 type=USER_AVC msg=audit(1563629683.384:155803): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { start } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/spamassassin.service" cmdline="" scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' ---- time->Sat Jul 20 15:34:43 2019 type=USER_AVC msg=audit(1563629683.394:155804): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=n/a uid=0 gid=0 cmdline="" scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=system permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Doing a moduleof my own again, I tried one with only the following rules: allow spamd_update_t init_t:system status; allow spamd_update_t systemd_unit_file_t:service start; Trying again, I got one more USER_AVC: type=USER_AVC msg=audit(1563630845.949:156395): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='avc: denied { status } for auid=n/a uid=0 gid=0 path="/usr/lib/systemd/system/spamassassin.service" cmdline="" scontext=system_u:system_r:spamd_update_t:s0 tcontext=system_u:object_r:systemd_unit_file_t:s0 tclass=service permissive=0 exe="/usr/lib/systemd/systemd" sauid=0 hostname=? addr=? terminal=?' Adding that too to my module, everything seems to finally work.
selinux-policy-3.14.3-41.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
As before, reopening since not fully resolved.
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. 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 '30'. 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 30 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.
There is one remaining problem mentioned her, but in order to not make an already messy report even worse, I put that in the separate bug 1831559.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.