Questions about enriched format and Node on RHEL 7.4

Steve Grubb sgrubb at redhat.com
Mon Aug 7 16:48:02 UTC 2017


Hello,

On Monday, August 7, 2017 11:25:38 AM EDT Maupertuis Philippe wrote:
> With Rhel 7.4 just out, I am giving a try at the new audit.
> Something seems strange to me.
> With the default log_format = RAW in auditd.conf, I get the node= parameter
> right in rsyslog (through the syslog plugin). If I switch to log_format =
> ENRICHED the parameter is missing altogether (no node=)

Where are you setting the log parameter? I mentioned in the release notes to 
audit-2.6 that the event is completely formatted in auditd when in enriched 
mode and that setting the name in audispd is no longer needed for enriched 
events. 

https://www.redhat.com/archives/linux-audit/2016-June/msg00053.html

Maybe the note should have said no longer possible. This is because auditd can 
now direct remote events that it collected to audispd so that you can have one 
plugin that can see all events for all systems. audispd does not parse events 
as it has no time to do so. This means it cannot tell where the event came 
from. So we make the assumption that when handling enriched events (which can 
only be generated newer auditd) to keep hands off because it might not be a 
locally originating event. 

So, I think the answer is put the same setting for name_format into 
auditd.conf that you have for audispd.conf.  Then everything should work out.


> In both case local there is no node parameter in the local audit.log.
> When I run ausearch --format text  from the  local host I never get node
> information. When I run it from the data received by rsyslog (after
> stripping the prefix with sed 's/^.*audispd://'), I get the node
> information for the RAW format only.
> 
> Another point that bothers me is that I got an extra line did-unknown after
> each meaningful line when I use the remote content (RAW or ENRICHED) This
> is what I get locally
> At 16:03:55 07/08/17 fr18358, acting as root, successfully executed
> /bin/pkg-config At 16:03:55 07/08/17 fr18358, acting as root, successfully
> executed /usr/libexec/grepconf.sh At 16:03:55 07/08/17 fr18358, acting as
> root, successfully opened-file /dev/tty using grepconf.sh At 16:03:55
> 07/08/17 fr18358, acting as root, successfully executed /bin/grep This is
> what I get from remote data
> At 15:43:52 07/08/17 fr18358, acting as root, successfully executed
> /bin/pkg-config At 15:43:52 07/08/17  did-unknown
> At 15:43:52 07/08/17 fr18358, acting as root, successfully executed
> /usr/libexec/grepconf.sh At 15:43:52 07/08/17  did-unknown
> At 15:43:52 07/08/17 fr18358, acting as root, successfully opened-file
> /dev/tty using grepconf.sh At 15:43:52 07/08/17  did-unknown
> At 15:43:52 07/08/17 fr18358, acting as root, successfully executed
> /bin/grep

I'd have to see the raw events to see what's going on. I'd be happy to look 
into it. You can send the events off list if you prefer. I only need a couple 
that shows the problem formatted with --raw.

-Steve

> !!!*************************************************************************
> ************ "Ce message et les pi?ces jointes sont confidentiels et
> r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre
> prot?g? par le secret professionnel. Si vous recevez ce message par erreur,
> merci d'en avertir imm?diatement l'exp?diteur et de le d?truire.
> L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la
> responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de
> ce message. Bien que les meilleurs efforts soient faits pour maintenir
> cette transmission exempte de tout virus, l'exp?diteur ne donne aucune
> garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour
> tout dommage r?sultant d'un virus transmis.
> 
> This e-mail and the documents attached are confidential and intended solely
> for the addressee; it may also be privileged. If you receive this e-mail in
> error, please notify the sender immediately and destroy it. As its
> integrity cannot be secured on the Internet, the Worldline liability cannot
> be triggered for the message content. Although the sender endeavours to
> maintain a computer virus-free network, the sender does not warrant that
> this transmission is virus-free and will not be liable for any damages
> resulting from any virus transmitted.!!!"





More information about the Linux-audit mailing list