SELinux is preventing mktemp from using the dac_read_search capability.

[Robert Moskowitz]

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                          <Unknown>
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

_______________________________________________
selinux mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
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/[e-mail]...

Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Ed Greshko]

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                          <Unknown>
> 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?

[Robert Moskowitz]

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                          <Unknown>
> > 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

[Ed Greshko]

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                          <Unknown>
> > > 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?

[Robert Moskowitz]

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                          <Unknown>
> > > > 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

[Samuel Sieb]

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?

[Robert Moskowitz]

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.

[George N. White III]

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.

[Robert Moskowitz]

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.

[Roger Heflin]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure