It looks like you may be right that it's /proc/net

Have you tried using the python audit tools such as audit2text to analyze them they can make it a lot easier to understand what's going on, though they usually don't tell you if there is a bool you can flip to fix it.
That tool still needs to be written :)
  Original Message  
From: [log in to unmask]
Sent: July 17, 2017 2:16 PM
To: [log in to unmask]
Subject: selinux preventing access to directory net

On two SL7.3 systems where I have set exim as my mta alternative, I am 
getting a lot of entries in /var/log/messages saying "SELinux is 
preventing /usr/bin/exim from search access on the directory net", with 
the usual accompanying "if you believe that exim should be allowed..." 
stuff, but the logs don't explain what call to exim triggered the 
messages.

Sealert -l tells me

Raw Audit Messages
type=AVC msg=audit(1500313603.937:268): avc:  denied { search } for 
pid=3097 comm="exim" name="net" dev="proc" ino=7154 
scontext=system_u:system_r:exim_t:s0 
tcontext=system_u:object_r:sysctl_net_t:s0 tclass=dir

type=SYSCALL msg=audit(1500313603.937:268): arch=x86_64 syscall=open 
success=no exit=EACCES a0=7ff03baef4b0 a1=80000 a2=1b6 a3=24 items=0 
ppid=781 pid=3097 auid=4294967295 uid=0 gid=93 euid=0 suid=0 fsuid=0 
egid=93 sgid=93 fsgid=93 tty=(none) ses=4294967295 comm=exim 
exe=/usr/sbin/exim subj=system_u:system_r:exim_t:s0 key=(null)

which doesn't seem to be much help.

Searches turn up two Centos 7 reports,
https://bugs.centos.org/view.php?id=13247 and 
https://bugs.centos.org/view.php?id=12913 that look as if they might be 
the same thing with different mta alternatives, but no response to 
either.

All that the mta is supposed to be doing on these systems is reporting 
the output of cron jobs, and that appears to be happening correctly, so 
I am puzzled as to what this is about.  I'm not even sure what net 
directory is being referred to.  /proc/net?  Does an mta need to look in 
that directory?  I can send mail internally, to and from my local user 
and root, and that doesn't provoke selinux messages in the logs.

Any suggestions for where to look?

Thanks,

Stephen Isard