Re: SELinux is preventing mktemp from using the dac_read_search capability.
dac_read_search says that linux permissions are denying access. and it says the file is /etc/shadow, and no one except root is supposed to be able to read that file. So whatever is trying to read /etc/shadow should not be trying to read it, and makes me wonder what is going on, and/or why some process is trying to read that file. The only reason to read /etc/shadow (outside of the system validating a password) is to get the hashed passwords so that you can attempt to break passwords with a cracker someplace else. On Thu, Jan 6, 2022 at 10:53 AM George N. White III wrote: > > On Thu, 6 Jan 2022 at 11:13, Robert Moskowitz wrote: >> >> >> >> On 1/5/22 23:10, Samuel Sieb wrote: >> > On 1/5/22 18:18, Robert Moskowitz wrote: >> >> On 1/5/22 21:16, Ed Greshko wrote: >> >>> On 06/01/2022 09:25, Robert Moskowitz wrote: >> >> >> On 1/5/22 17:17, Ed Greshko wrote: >> > On 05/01/2022 21:02, Robert Moskowitz wrote: >> >> >> >> If you want to help identify if domain needs this access or you >> >> have a file with the wrong permissions on your system >> >> Then turn on full auditing to get path information about the >> >> offending file and generate the error again. >> >> Do >> >> >> >> Turn on full auditing >> >> # auditctl -w /etc/shadow -p w >> >> Try to recreate AVC. Then execute >> >> # ausearch -m avc -ts recent >> >> If you see PATH record check ownership/permissions on file, and >> >> fix it, >> >> otherwise report as a bugzilla. >> > >> > These instructions could be useful to find out what it's trying to >> > access. >> >> Considering how random this appears to be, I would have to turn full >> auditing on for some time. Plus they don't provide how to turn it back >> off. >> >> > >> >> Additional Information: >> >> Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 >> >> Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 >> > >> >> # ls -Z /usr/sbin/logwatch >> >> system_u:object_r:bin_t:s0 /usr/sbin/logwatch >> > >> > This isn't really useful. The problem is that it's being run from the >> > context listed above and that's what is being denied. Depending on >> > what it's trying to access, it might be an issue for the selinux policy. >> > >> > Are you running it as a systemd service or running it from cron? >> >> All I did was dnf install logwatch. No customization. Yet. >> >> I see in /var/log/cron a daily cron activity for logwatch. > > > Do you have "man 8 logwatch_selinux"? If not, google can > find it. > > https://launchpad.net/msmtp-scripts/+announcement/15310 says: > A packaging update has been released for EL7/Fedora that addresses > an issue with using logwatch with SELinux enabled and enforcing > and msmtp-scripts as MTA. It's not in the COPRs. > > > -- > George N. White III > > ___ > users mailing list -- users@lists.fedoraproject.org > To unsubscribe send an email to users-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 1/6/22 11:53, George N. White III wrote: On Thu, 6 Jan 2022 at 11:13, Robert Moskowitz wrote: On 1/5/22 23:10, Samuel Sieb wrote: > On 1/5/22 18:18, Robert Moskowitz wrote: >> On 1/5/22 21:16, Ed Greshko wrote: >>> On 06/01/2022 09:25, Robert Moskowitz wrote: On 1/5/22 17:17, Ed Greshko wrote: > On 05/01/2022 21:02, Robert Moskowitz wrote: >> >> If you want to help identify if domain needs this access or you >> have a file with the wrong permissions on your system >> Then turn on full auditing to get path information about the >> offending file and generate the error again. >> Do >> >> Turn on full auditing >> # auditctl -w /etc/shadow -p w >> Try to recreate AVC. Then execute >> # ausearch -m avc -ts recent >> If you see PATH record check ownership/permissions on file, and >> fix it, >> otherwise report as a bugzilla. > > These instructions could be useful to find out what it's trying to > access. Considering how random this appears to be, I would have to turn full auditing on for some time. Plus they don't provide how to turn it back off. > >> Additional Information: >> Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 >> Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 > >> # ls -Z /usr/sbin/logwatch >> system_u:object_r:bin_t:s0 /usr/sbin/logwatch > > This isn't really useful. The problem is that it's being run from the > context listed above and that's what is being denied. Depending on > what it's trying to access, it might be an issue for the selinux policy. > > Are you running it as a systemd service or running it from cron? All I did was dnf install logwatch. No customization. Yet. I see in /var/log/cron a daily cron activity for logwatch. Do you have "man 8 logwatch_selinux"? If not, google can find it. Don't have it. tried: ps -eZ | grep logwatch_t as the man says, but it comes up empty. https://launchpad.net/msmtp-scripts/+announcement/15310 says: A packaging update has been released for EL7/Fedora that addresses an issue with using logwatch with SELinux enabled and enforcing and msmtp-scripts as MTA. It's not in the COPRs. Just ran dnf update, and did not see anything new for logwatch or SELinux. New kernel 5.15.12 Logwatch is still what I installed: 2021-11-14T15:04:02-0500 SUBDEBUG Installed: logwatch-7.5.6-2.fc35.noarch SElinux was recently upgraded: 2021-12-26T08:31:55-0500 SUBDEBUG Upgrade: selinux-policy-35.7-1.fc35.noarch 2021-12-26T08:32:27-0500 SUBDEBUG Upgrade: selinux-policy-targeted-35.7-1.fc35.noarch Which is what was running in the report I posted. So either no update yet, or this updated does not impact my problem. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On Thu, 6 Jan 2022 at 11:13, Robert Moskowitz wrote: > > > On 1/5/22 23:10, Samuel Sieb wrote: > > On 1/5/22 18:18, Robert Moskowitz wrote: > >> On 1/5/22 21:16, Ed Greshko wrote: > >>> On 06/01/2022 09:25, Robert Moskowitz wrote: > > > On 1/5/22 17:17, Ed Greshko wrote: > > On 05/01/2022 21:02, Robert Moskowitz wrote: > >> > >> If you want to help identify if domain needs this access or you > >> have a file with the wrong permissions on your system > >> Then turn on full auditing to get path information about the > >> offending file and generate the error again. > >> Do > >> > >> Turn on full auditing > >> # auditctl -w /etc/shadow -p w > >> Try to recreate AVC. Then execute > >> # ausearch -m avc -ts recent > >> If you see PATH record check ownership/permissions on file, and > >> fix it, > >> otherwise report as a bugzilla. > > > > These instructions could be useful to find out what it's trying to > > access. > > Considering how random this appears to be, I would have to turn full > auditing on for some time. Plus they don't provide how to turn it back > off. > > > > >> Additional Information: > >> Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 > >> Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 > > > >> # ls -Z /usr/sbin/logwatch > >> system_u:object_r:bin_t:s0 /usr/sbin/logwatch > > > > This isn't really useful. The problem is that it's being run from the > > context listed above and that's what is being denied. Depending on > > what it's trying to access, it might be an issue for the selinux policy. > > > > Are you running it as a systemd service or running it from cron? > > All I did was dnf install logwatch. No customization. Yet. > > I see in /var/log/cron a daily cron activity for logwatch. > Do you have "man 8 logwatch_selinux"? If not, google can find it. https://launchpad.net/msmtp-scripts/+announcement/15310 says: A packaging update has been released for EL7/Fedora that addresses an issue with using logwatch with SELinux enabled and enforcing and msmtp-scripts as MTA. It's not in the COPRs. -- George N. White III ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 1/5/22 23:10, Samuel Sieb wrote: On 1/5/22 18:18, Robert Moskowitz wrote: On 1/5/22 21:16, Ed Greshko wrote: On 06/01/2022 09:25, Robert Moskowitz wrote: On 1/5/22 17:17, Ed Greshko wrote: On 05/01/2022 21:02, Robert Moskowitz wrote: If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. These instructions could be useful to find out what it's trying to access. Considering how random this appears to be, I would have to turn full auditing on for some time. Plus they don't provide how to turn it back off. Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 # ls -Z /usr/sbin/logwatch system_u:object_r:bin_t:s0 /usr/sbin/logwatch This isn't really useful. The problem is that it's being run from the context listed above and that's what is being denied. Depending on what it's trying to access, it might be an issue for the selinux policy. Are you running it as a systemd service or running it from cron? All I did was dnf install logwatch. No customization. Yet. I see in /var/log/cron a daily cron activity for logwatch. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 1/5/22 18:18, Robert Moskowitz wrote: On 1/5/22 21:16, Ed Greshko wrote: On 06/01/2022 09:25, Robert Moskowitz wrote: On 1/5/22 17:17, Ed Greshko wrote: On 05/01/2022 21:02, Robert Moskowitz wrote: If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. These instructions could be useful to find out what it's trying to access. Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 # ls -Z /usr/sbin/logwatch system_u:object_r:bin_t:s0 /usr/sbin/logwatch This isn't really useful. The problem is that it's being run from the context listed above and that's what is being denied. Depending on what it's trying to access, it might be an issue for the selinux policy. Are you running it as a systemd service or running it from cron? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 1/5/22 21:16, Ed Greshko wrote: On 06/01/2022 09:25, Robert Moskowitz wrote: On 1/5/22 17:17, Ed Greshko wrote: On 05/01/2022 21:02, Robert Moskowitz wrote: I keep getting these errors. I got them back with F32 and Xfce, and now with F35 and Xfce. I asked on the SElinux list, but no one seems to be home. Here is the full detail; it looks like it may be logwatch causing the problem. What do I do to fix this? === SELinux is preventing mktemp from using the dac_read_search capability. * Plugin dac_override (91.4 confidence) suggests ** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. * Plugin catchall (9.59 confidence) suggests ** If you believe that mktemp should have the dac_read_search capability 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 'mktemp' --raw | audit2allow -M my-mktemp # semodule -X 300 -i my-mktemp.pp Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source mktemp Source Path mktemp Port Host lx140e.htt-consult.com Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Local Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name lx140e.htt-consult.com Platform Linux lx140e.htt-consult.com 5.15.11-200.fc35.x86_64 #1 SMP Wed Dec 22 15:41:11 UTC 2021 x86_64 x86_64 Alert Count 13912 First Seen 2021-11-15 03:27:05 EST Last Seen 2022-01-02 03:09:16 EST Local ID 2ef8a1a9-ddf5-42cc-b5dc-c08354265cc8 Raw Audit Messages type=AVC msg=audit(1641110956.728:1612): avc: denied { dac_read_search } for pid=24078 comm="dotlockfile" capability=2 scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tclass=capability permissive=0 Hash: mktemp,logwatch_mail_t,logwatch_mail_t,capability,dac_read_search Before doing as suggested in the sealert output. What is the output of "ls -Z /usr/bin/dotlockfile" and "ls -X /usr/bin/mktemp"? # ls -Z /usr/bin/dotlockfile system_u:object_r:bin_t:s0 /usr/bin/dotlockfile # ls -X /usr/bin/mktemp /usr/bin/mktemp Ooops I made a typo. What is "ls -Z /usr/bin/mktemp" and also "ls -Z /usr/sbin/logwatch". # ls -Z /usr/bin/mktemp system_u:object_r:bin_t:s0 /usr/bin/mktemp # ls -Z /usr/sbin/logwatch system_u:object_r:bin_t:s0 /usr/sbin/logwatch ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 06/01/2022 09:25, Robert Moskowitz wrote: On 1/5/22 17:17, Ed Greshko wrote: On 05/01/2022 21:02, Robert Moskowitz wrote: I keep getting these errors. I got them back with F32 and Xfce, and now with F35 and Xfce. I asked on the SElinux list, but no one seems to be home. Here is the full detail; it looks like it may be logwatch causing the problem. What do I do to fix this? === SELinux is preventing mktemp from using the dac_read_search capability. * Plugin dac_override (91.4 confidence) suggests ** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. * Plugin catchall (9.59 confidence) suggests ** If you believe that mktemp should have the dac_read_search capability 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 'mktemp' --raw | audit2allow -M my-mktemp # semodule -X 300 -i my-mktemp.pp Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source mktemp Source Path mktemp Port Host lx140e.htt-consult.com Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Local Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name lx140e.htt-consult.com Platform Linux lx140e.htt-consult.com 5.15.11-200.fc35.x86_64 #1 SMP Wed Dec 22 15:41:11 UTC 2021 x86_64 x86_64 Alert Count 13912 First Seen 2021-11-15 03:27:05 EST Last Seen 2022-01-02 03:09:16 EST Local ID 2ef8a1a9-ddf5-42cc-b5dc-c08354265cc8 Raw Audit Messages type=AVC msg=audit(1641110956.728:1612): avc: denied { dac_read_search } for pid=24078 comm="dotlockfile" capability=2 scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tclass=capability permissive=0 Hash: mktemp,logwatch_mail_t,logwatch_mail_t,capability,dac_read_search Before doing as suggested in the sealert output. What is the output of "ls -Z /usr/bin/dotlockfile" and "ls -X /usr/bin/mktemp"? # ls -Z /usr/bin/dotlockfile system_u:object_r:bin_t:s0 /usr/bin/dotlockfile # ls -X /usr/bin/mktemp /usr/bin/mktemp Ooops I made a typo. What is "ls -Z /usr/bin/mktemp" and also "ls -Z /usr/sbin/logwatch". -- Did 황준호 die? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 1/5/22 17:17, Ed Greshko wrote: On 05/01/2022 21:02, Robert Moskowitz wrote: I keep getting these errors. I got them back with F32 and Xfce, and now with F35 and Xfce. I asked on the SElinux list, but no one seems to be home. Here is the full detail; it looks like it may be logwatch causing the problem. What do I do to fix this? === SELinux is preventing mktemp from using the dac_read_search capability. * Plugin dac_override (91.4 confidence) suggests ** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. * Plugin catchall (9.59 confidence) suggests ** If you believe that mktemp should have the dac_read_search capability 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 'mktemp' --raw | audit2allow -M my-mktemp # semodule -X 300 -i my-mktemp.pp Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source mktemp Source Path mktemp Port Host lx140e.htt-consult.com Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Local Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name lx140e.htt-consult.com Platform Linux lx140e.htt-consult.com 5.15.11-200.fc35.x86_64 #1 SMP Wed Dec 22 15:41:11 UTC 2021 x86_64 x86_64 Alert Count 13912 First Seen 2021-11-15 03:27:05 EST Last Seen 2022-01-02 03:09:16 EST Local ID 2ef8a1a9-ddf5-42cc-b5dc-c08354265cc8 Raw Audit Messages type=AVC msg=audit(1641110956.728:1612): avc: denied { dac_read_search } for pid=24078 comm="dotlockfile" capability=2 scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tclass=capability permissive=0 Hash: mktemp,logwatch_mail_t,logwatch_mail_t,capability,dac_read_search Before doing as suggested in the sealert output. What is the output of "ls -Z /usr/bin/dotlockfile" and "ls -X /usr/bin/mktemp"? # ls -Z /usr/bin/dotlockfile system_u:object_r:bin_t:s0 /usr/bin/dotlockfile # ls -X /usr/bin/mktemp /usr/bin/mktemp ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: SELinux is preventing mktemp from using the dac_read_search capability.
On 05/01/2022 21:02, Robert Moskowitz wrote: I keep getting these errors. I got them back with F32 and Xfce, and now with F35 and Xfce. I asked on the SElinux list, but no one seems to be home. Here is the full detail; it looks like it may be logwatch causing the problem. What do I do to fix this? === SELinux is preventing mktemp from using the dac_read_search capability. * Plugin dac_override (91.4 confidence) suggests ** If you want to help identify if domain needs this access or you have a file with the wrong permissions on your system Then turn on full auditing to get path information about the offending file and generate the error again. Do Turn on full auditing # auditctl -w /etc/shadow -p w Try to recreate AVC. Then execute # ausearch -m avc -ts recent If you see PATH record check ownership/permissions on file, and fix it, otherwise report as a bugzilla. * Plugin catchall (9.59 confidence) suggests ** If you believe that mktemp should have the dac_read_search capability 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 'mktemp' --raw | audit2allow -M my-mktemp # semodule -X 300 -i my-mktemp.pp Additional Information: Source Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Context system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 Target Objects Unknown [ capability ] Source mktemp Source Path mktemp Port Host lx140e.htt-consult.com Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Local Policy RPM selinux-policy-targeted-35.7-1.fc35.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name lx140e.htt-consult.com Platform Linux lx140e.htt-consult.com 5.15.11-200.fc35.x86_64 #1 SMP Wed Dec 22 15:41:11 UTC 2021 x86_64 x86_64 Alert Count 13912 First Seen 2021-11-15 03:27:05 EST Last Seen 2022-01-02 03:09:16 EST Local ID 2ef8a1a9-ddf5-42cc-b5dc-c08354265cc8 Raw Audit Messages type=AVC msg=audit(1641110956.728:1612): avc: denied { dac_read_search } for pid=24078 comm="dotlockfile" capability=2 scontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tcontext=system_u:system_r:logwatch_mail_t:s0-s0:c0.c1023 tclass=capability permissive=0 Hash: mktemp,logwatch_mail_t,logwatch_mail_t,capability,dac_read_search Before doing as suggested in the sealert output. What is the output of "ls -Z /usr/bin/dotlockfile" and "ls -X /usr/bin/mktemp"? -- Did 황준호 die? ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure