On Tuesday, July 21, 2015 01:23:49 PM Kangkook Jee wrote: > With our custom audit client, we prefer not to take too much resources (CPUs > or memory) from user machine and rather want to drop some events.
Maybe set a smaller backlog and tell it to ignore overflows? -b 512 -f 0 > Therefore I'm trying to use audit multicast feature you mentioned > (https://lwn.net/Articles/587166/). I found out that this feature is > recently added and I have a few questions using it. > > Q1. I've gone over journald source code and found out that it issues a > number of netlink socket api calls to join in multi-cast group and receive > datagrams. Do you support rather cleaner api to use this feature? I > couldn't find anything from libaudit.h. This is one for the kernel developers. > Q2. By joining in audit multi-cast group, can we avoid auditing the audit > client itself? As you know, with audit_set_pid(), it prevents from > gathering and reporting audit event for user-space audit client. We can > expect the same thing? You can set a rule once your program starts up and you have access to your pid. It would be the equivalent of this: -a never,exit -S all -F pid=<pid> > Q3. By only having a read-only user-space audit client and not having > bi-direction audit client running from the system, are we going to see > audit entries logged from default system log frameworks which output to > /var/log/kernel.log (Debian family), syslog, or dmesg? You should not. I know you said you looked at Journald as an example of how to do it. It might be joining a lot more than audit. I haven't looked. > Q4. Our environment for deployment comprises many different types of legacy > distributions (i.e., CentOS 5 or 6, Ubuntu 12.04 ...), could you inform me > from what audit version (or kernel version) audit multicast is supported? It seems to be 3.16. > Q5. I'm also considering another design choice to use *rate_limit* to limit > the amount of audit messages delivered to user-level client. Do you think > kauditd will drop some messages with this setting enabled? I have not played with it. Maybe one of the kernel developers has an opinion. I am pretty sure you can just ignore queue overflows, though. -Steve -- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
