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 <gnwiii@xxxxxxxxx> wrote: > > On Thu, 6 Jan 2022 at 11:13, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
