Proposal: New Auditd Design

[Junji Kanemaru]

> I would think it could be tunneled using ssh or a vpn. A plug-in shouldn't be 
> needed.

When log out to remote host we need the remote host to response back status
if the log has been written or failed. Network logging must be some kind of
transaction. I'd use D-BUS/RPC or XMLRPC for this. I have done some
tiny fast encrypted XMLRPC protocol that uses RSA with MAC though I cannot
put it public place now, we may be able to use it in the future.

Anyway logging to remote host could be very slow comparing to writing to
disk.
So either way you need to change current code to do more multi threading
with buffering to do remote logging because current implementation is
serialized I/O, main process which reads netlink socket is blocked until
writing
to disk completes. I'm not sure how busy the audit events come in from
kernel,
auditd could drop some packets. So I did plugin with multi threading to
minimize
the risk of packet drop.

However I don't know if people who use auditd want serialized I/O and don't
care packet drops if it is too busy to handle. I did plugin support to avoid
audit packet drops. My version writes to disk(network) whenever consumer
thread(s) get CPU. Thus there some audit logs stay on memory certain time
until they are written to disk.
Let me know if you did serialized I/O for the purpose that caching log on
memory causes some issues for people who use auditd.

Thanks

-- 
Junji Kanemaru
Linuon Inc.
Tokyo Japan