I need to add custom audit records to the audit log within RedHat 5.2. I need custom records because they don't pertain to any type of system call or file operation so there is no way for the Audit daemon to generate them using rules (at least not that I know of).

At later time I also need to extract the customized audit records as well as the Audit records that are generated by audit rules, from the audit log and then offload them to another host. In other words, I'd like to use the functionality provided by auditd as temporary storage of audit records then I'd like to remove audit records from the log and offload them.

Does the Auditd provide any type of interface to do these things? If so, how do I interface with it?

Thanks in advance.

Steve Grubb has a small section on audit dispatching. I think that may be pertinent to the offloading I'm trying to do. I'm still unsure about the ability to generate custom records though. http://people.redhat.com/sgrubb/audi...-rt-events.txt

Interesting! Care to share (example?) what it is about? And why they need to be tagged as audit records and why KERN_.* facility ones don't cut it?



AFAIK you should be able to use Auditd as a conduit and have it log to remote all by itself.


As far as I understand it, Auditd is only the userspace component. It provides logging to file and that's basically it (evidenced by the fact that if auditd fails or if you don't run auditd the messages are handled OK by syslogd). Wrt the rules part, adding rules with auditctl you could compare to iptables: the userland utility doesn't do more than offer the kernel instructions on what to look at. So you'll have to look at the kernel part because Auditd *can* accept userland messages. I think a nice example might be to follow for instance the inception of AUDIT_USER_TTY in the kernel and Auditd source. Maybe it could give you an idea what you need to have the kernel accept a userland message and push it through to Auditd. But then again I'm no Linux guru so I may be horribly wrong...

It involves virtual machines (VMs). Different VMs are responsible for different tasks. One VM receives data (audit records of a different format from a different type of system) that I'd like to store in the auditd log, if possible. This allows both the received data and locally generated audit records to be stored in a single location in a predefined format within the auditd log. The records and data in the auditd log will periodically need to be offloaded to another VM. Using the auditd infrastructure to perform this duel-role (storing audit records of a different format from a different type of system and storing locally generated audit records) will significantly reduce development time. The main problem is finding some type of interface or mechanism to use so I can write custom records to the auditd log without stepping on the auditd's toes.

Because our system is using VMs on top of a hypervisor its unlikely that any conduit capabilities or remote logging capabilities the auditd has will be of much use. Luckily we already have code created that can perform the offloading task to another VM. However, I am currently looking into the best way to read from the auditd log and remove older entries so I can use the offloading mechanism. I have plenty of ideas about how I could do this but if there is some interface that the auditd provides that would be the optimal choice. Then I wouldn't have to worry so much about stepping on the auditd's toes with custom code.

Its beginning to seem more and more like that is true. I can always edit the kernel but there are probably better options than to go down that route.

I've been going through a lot of the internal code but its not commented much and there is almost no documentation out there except for how to use autrace, auditctl, and aureport, which isn't what I need. I did find a SUSE document buts its solely focused on the administration of the auditd.

Its a start. I'll look it over.

No harm in trying. I'm not very Linux savvy myself so any advice is always appreciated.

Looking at your motivation for your offloading mechanism ("reduce development time") and unless you need to run ops on both those audit records before offloading, and with all due respect, but this sounds like aggregation gone wrong to me. The Linux Audit framework is not about extensibility but about the kernel getting audit records to userland fast. It's not comparable to something like the Prelude panoply of auditing apps.


Hypervisors have nothing to do with that type of logging as it's basic networking functionality.


Nowhere I suggested the necessity for editing kernel code. I'm only pointing at certain hooks in the audit and kernel code that could help get you ideas for logging.


Since this is not a Linux Security issue but a programming one I will move this thread to the Linux Kernel forum to get your questions the exposure they deserve.

Estimating complexity and development time are easily some of the more important aspects in design. I was inquiring about the audit daemon because it seems possible to re-use code rather than to develop, integrate, and test a whole new module that would perform many things that the audit daemon already does: storing records and offloading records, overflow options, formatting, contention resolution, error handling, etc.

Also, the offloading mechanism isn't an issue. That aspect is already taken care of. There are two main issues to resolve:
1) What is the best way to read records from the audit daemon without stepping on the audit daemons toes; I.E., does the audit daemon provide some type of interface to read from the log and remove old records? (aureport only reads the log)

2) Can custom audit records be added to the audit log. For example, can a trusted app somehow store a record within the audit log that contains information that the trusted app would somehow pass to the audit daemon for logging.

I was not insinuating that you were. I was simply throwing a possible solution out there that I had considered. It appears you agree that there are probably better options.

Well I am only looking for information to better understand the limitations and constraints of the audit daemon. Understanding the problem I am attempting to resolve is important to give context to my questions but isn't necessary. Thanks for your help.

Custom audit records can be added. Though I'm not yet sure how to customize fields. However, one could serialize data into a large field such as the "message" field:

http://www.mail-archive.com/linux-au.../msg01093.html