On 2/28/23 11:39, Murali Selvaraj wrote:
Hi John,
I added below entries in one of my profiles which runs under complain mode.
*audit /var/** wl,*
what kernel version? I will note that there are two know bugs around auditing.
One of them is fixed, the other is currently being worked on.
I am not sure if this one would be affected by the second bug but if you are
seeing the messages with -a I would say no.
As per my script to capture Apparmor logs, I am capturing journalctl -k for
every 30 mins in my log path (for instance, /tmp/logs/).
However, I could NOT see the expected log entry for this rule audit "/var/**
wl," from journalctl -k output.
do you know which path the journal is pulling the apparmor logs? via the audit
subsystem (auditd installed) or via the kernel log path.
I could see the logs seen if we use *journalctl -a*, but I do not want to copy
(to avoid the space) journalctl -a for every 30 mins as it has other
additional/debug log information.
This to me says you have auditd installed which means apparmor messages are not
going to dmesg, but instead routed through audit. Since AppArmor is using the
audit subsystem for logging the decision of where the messages go is up to the
audit subsystem, if auditd is installed they will go there
Unfortunately at this time apparmor doesn't have finer control over this than
what auditd provides. There is work to improve apparmor auditing which will
allow more options but that hasn't landed yet, and the portion to would allow
the complain redirect isn't even implemented yet.
Do we have any options/configuration to get these logs from *journalctl -k
*instead of*journalctl -a*?
you can try disabling auditd
auditctl-e0
or potentially filtering based on the transport using journalctl -af
_TRANSPORT=audit
Thanks
Murali.S
