I've added the option "use_dns(yes);" and am allowing messages from the
local network.  With this small configuration adjustment in place, I see
the kernel log getting severely spammed by AppArmor:

[######.######] audit: type=1400 audit(####################): apparmor="ALLOWED" operation="open" profile="syslog-ng" name="/proc/<misc-pid>/cmdline" pid=<syslog-ng-pid> comm="syslog-ng" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[######.######] audit: type=1400 audit(####################): apparmor="ALLOWED" operation="open" profile="syslog-ng" name="/proc/<misc-pid>/loginuid" pid=<syslog-ng-pid> comm="syslog-ng" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[######.######] audit: type=1400 audit(####################): apparmor="ALLOWED" operation="open" profile="syslog-ng" name="/proc/<misc-pid>/sessionid" pid=<syslog-ng-pid> comm="syslog-ng" requested_mask="r" denied_mask="r" fsuid=0 ouid=0


I'm cautiously optimistic this is due to the AppArmor profile for
syslog-ng being incomplete and not someone having broken into this
machine and done something to syslog-ng.

I had suspected something along these lines, but I've confirmed the
misc-pid syslog-ng is accessing in /proc is the one sending the message
to syslog-ng.

The real problem is this is generating so much noise in the logs that
everything else is being lost.

Hi,

Elliott Mitchell (2020-06-14):

It looks like it, indeed.

Please report upstream any problem with an AppArmor profile that is
included in the apparmor-profiles package:

https://gitlab.com/apparmor/apparmor/-/issues

The apparmor-profiles package exists solely to provide a way for users
to test these experimental profiles and help improve them upstream
if needed. Do not expect these profiles to work out-of-the-box.