From mboxrd@z Thu Jan 1 00:00:00 1970 From: LC Bruzenak Subject: Re: plugin auditing approach question Date: Mon, 23 Jun 2008 12:53:27 -0500 Message-ID: <1214243607.6564.38.camel@homeserver> References: <1214242045.6564.25.camel@homeserver> <200806231336.18477.sgrubb@redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <200806231336.18477.sgrubb@redhat.com> 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 Mon, 2008-06-23 at 13:36 -0400, Steve Grubb wrote: > On Monday 23 June 2008 13:27:25 LC Bruzenak wrote: > > I would create a library call and matching executable audit proxy. I'd > > give CAP_AUDIT_WRITE to the proxy. Then, the library call would > > fork/exec the audit proxy child, create a socket pair, and give each > > side their half of the pair. > > So then you have shifted access control issues to the proxy. Once you have a > proxy, then other potentially misleading apps can write to it in order to > hide or make it hard to analyze a suspicious event. So, you need a way of > making sure that only certain apps can connect to the proxy...and bash should > not be one of them. :) Anyways, that is the core issue that I see. > > -Steve Yes. That is exactly right, which is why we are also thinking about maybe "typing" the ones we plugin, adding appropriate policy and enforcing that. Other option is we can also audit as much of the parent info as possible, specifically denying connections from a shell or other naughty-minded applications. I guess we can get the irrefutable parent info from /proc (not sure what CAPS I need to read the parent process info), right? Thx again, I do appreciate the feedback. LCB. -- LC (Lenny) Bruzenak lenny@magitekltd.com