audispd syslog plugin config limits choice of syslog facility and doesn't allow 13 "Log audit"

[JPvRiel]

As per RFC3164 for syslog describing facilities, I wondered if the "log audit" facility can be used.

13 log audit (note 1)

One might think, after reading specs, facility 13 would be a good choice for where to send audit events. However, as per https://github.com/linux-audit/audit-userspace/blob/31784eda120d28c19414a5109310c7c189150858/audisp/audispd-builtins.c#L291

There are a limited number of facilities one can parse as arguments, and 13 is not catered for.

I appreciate the complexity arose given older unix platforms syslog.h files and glibc didn't take the time to define all the facilities (possibly syslog.h was written before RFC3164 was authored as a retrospective standard) , e.g. syslog.3. Out of interest freebsd has LOG_SECURITY defined for facility 13. So it seems the Linux community and libc devs opted to never use 13 for audit security events, which is a pity, because things like local6 can sometimes conflict with other programs also using local facilities.

Might it not be a good idea to align to the RFC and default to facility 13, which as far as I can tell, most other linux processes don't use. But is the complication that one can't actually use 13 because it's not defined properly in glibc?

[stevegrubb]

Security events wind up in /var/log/secure. This is in coordination with rsyslog.conf having authpriv.* mapped to that file. Glibc does not define facility codes 12 - 15. So, I take it that this is more of an architectural thing rather than something that audit alone should address. Glibc, rsyslog, and audit would all need to be updated to use the LOG_AUDIT facility. I also think 3rd party tools may need updating too as this would be a new facility as far as log analysis vendors is concerned.

The next concern would be mapping the events to proper severity ratings. I'm afraid that to ask for the creation of LOG_AUDIT would mean to people that it gets first class support. Which is not anything that I'm wanting to do at this point. For first class support means we need to get the severity right all the time. The reality is that events are mixed. Some are informational, some noticeable, and some are alert. I don't think there is a good mechanism to express this at the source where it is known what the event means.

To summarize, interesting thought. But I don't see a good reason to go down this path right now.

[JPvRiel]

this is more of an architectural thing rather than something that audit alone should address. Glibc, rsyslog, and audit would all need to be updated to use the LOG_AUDIT facility.

Agree, the neighbouring ecosystem unfortunately neglects using LOG_AUDIT for the most part, so aiming to align this to RFC3164 doesn't help if most other logging products ignored that part of the RFC.

I'd suggest closing this issue, and, if ever the surrounding ecosystem corrects to try follow the RFC, then re-open. And noticing how poorly RFC5424 has been adopted, it's unlikely things will change.