From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Dennis Subject: Re: Audit for live supervision Date: Tue, 19 Aug 2008 10:14:54 -0400 Message-ID: <48AAD55E.5070408@redhat.com> References: <200808140914.07779.kayhayen@gmx.de> <200808161319.28048.kayhayen@gmx.de> <200808181110.24294.sgrubb@redhat.com> <200808190845.01023.kayhayen@gmx.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0838980233==" Return-path: In-Reply-To: <200808190845.01023.kayhayen@gmx.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Kay Hayen Cc: alex@segv.de, linux-audit@redhat.com List-Id: linux-audit@redhat.com This is a multi-part message in MIME format. --===============0838980233== Content-Type: multipart/alternative; boundary="------------010800080009040506010606" This is a multi-part message in MIME format. --------------010800080009040506010606 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kay Hayen wrote: > No, when opening the socket the to the sub deamon audisp. I couldn't convice > myself how the API would work with a socket. Does it? > The auparse library can read a stream by opening the parser with AUSOURCE_FEED, you set a callback, then feed arbitrary number of bytes into the parser by calling auparse_feed(), you'll be called back when a complete event is found, at that point just use the normal auparse functions. You can read off of this unix socket (/var/run/audispd_events) but this is deprecated. It is now preferred is now to use a audispd plugin and read from stdin. See the audit src package and look in audisp/plugins for examples. FWIW I noticed that code was calling fgets to get data to feed to auparse_feed() but it seems inefficient to buffer lines twice, auparse_feed will do the line protocol. > I read that as that we can use the netlink socket with the libaudit directly, > which sort of could be exactly what we want. That would mean we wouldn't use > audit user space (processes) at all, right? > > No, you really want to use the user space interface (see above). > >> You have 4 points to get the audit stream, in order of distance from the >> event generation: the audit netlink socket, auditd realtime interface, >> audisp plugin interface, and the af_unix socket created by the af_unix >> plugin from audispd. For higher reliability where you don't want of need >> any other audit processing interfering, I would say use either of the first >> 2. >> > > The latency is getting higher with each step. For optimal performance we would > listen to the netlink socket and duplicate only the code essential to process > what we are interested it. > > For extra points and hurt, we would do it in Ada and inside the target > process, really achieving the low latency. It may be the only realistic > option, but it also feels like duplication of effort. We have done netlink > interfaces in Ada before, but also have on our mind that it was said that the > netlink interface was said (not by you) to be still in flux. Is that still > true? > > It certainly would be nice if the audisp had some form of output that can be > fed directly into libaudit parsing as it comes in. But that may be an > unrealistic expectation, is it? > > It does, see above comment. -- John Dennis --------------010800080009040506010606 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Kay Hayen wrote: 
No, when opening the socket the to the sub deamon audisp. I couldn't convice 
myself how the API would work with a socket. Does it?

The auparse library can read a stream by opening the parser with AUSOURCE_FEED, you set a callback, then feed arbitrary number of bytes into the parser by calling auparse_feed(), you'll be called back when a complete event is found, at that point just use the normal auparse functions.

You can read off of this unix socket (/var/run/audispd_events) but this is deprecated. It is now preferred is now to use a audispd plugin and read from stdin. See the audit src package and look in audisp/plugins for examples. FWIW I noticed that code was calling fgets to get data to feed to auparse_feed() but it seems inefficient to buffer lines twice, auparse_feed will do the line protocol.
I read that as that we can use the netlink socket with the libaudit directly, 
which sort of could be exactly what we want. That would mean we wouldn't use 
audit user space (processes) at all, right?
No, you really want to use the user space interface (see above).
  
You have 4 points to get the audit stream, in order of distance from the
event generation: the audit netlink socket, auditd realtime interface,
audisp plugin interface, and the af_unix socket created by the af_unix
plugin from audispd. For higher reliability where you don't want of need
any other audit processing interfering, I would say use either of the first
2.
    

The latency is getting higher with each step. For optimal performance we would 
listen to the netlink socket and duplicate only the code essential to process 
what we are interested it. 

For extra points and hurt, we would do it in Ada and inside the target 
process, really achieving the low latency. It may be the only realistic 
option, but it also feels like duplication of effort. We have done netlink 
interfaces in Ada before, but also have on our mind that it was said that the 
netlink interface was said (not by you) to be still in flux. Is that still 
true?

It certainly would be nice if the audisp had some form of output that can be 
fed directly into libaudit parsing as it comes in. But that may be an 
unrealistic expectation, is it?
It does, see above comment.


-- 
John Dennis <jdennis@redhat.com>
--------------010800080009040506010606-- --===============0838980233== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0838980233==--