From mboxrd@z Thu Jan 1 00:00:00 1970 From: Richard Guy Briggs Subject: Re: [PATCH 0/6][v2] audit: implement multicast socket for journald Date: Tue, 7 Oct 2014 00:09:46 -0400 Message-ID: <20141007040946.GI26201@madcap2.tricolour.ca> References: <20140422.161904.1187535812839850973.davem@davemloft.net> <26389161.vp9iWSVLPX@x2> <1398225475.750.7.camel@localhost> <4319780.ABUmAV9CjH@x2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <4319780.ABUmAV9CjH@x2> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Steve Grubb Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com On 14/04/28, Steve Grubb wrote: > Hello, > > Removing people that probably could care less about an audit event... > > On Tuesday, April 22, 2014 11:57:55 PM Eric Paris wrote: > > > Also, shouldn't we have an audit event for every attempt to connect to > > > this socket? We really need to know where this information is getting > > > leaked to. > > > > We certainly can. What would you like to see in that event? > > I think it should be patterned after the other "standalone" kernel audit > events. We need pid, sesion, uid, auid, subj, comm, exe, and results. The > event type should be something like AUDIT_EVENT_LISTENER. I am wondering about > the usefulness of also adding op=connect op=disconnect to bracket the times > when something else was listening in on audit events. I assume that order of these is not yet important and that gid should also be in this list (which will let me use audit_log_task()). > -Steve - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545