plugin auditing approach question

plugin auditing approach question

[LC Bruzenak]

In our system we need to supply some specialized plugins to, for example
evolution, which will be doing things that we desire to audit. However,
we don't want to assign CAP_AUDIT_WRITE to evolution.

I have an approach on which I wanted to get some feedback.

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.

The sockets would persist until an explicit close (another library call,
so that it told the proxy client to shut down through the socket
interface) happened, so subsequent audits could use the interface.
Also the child proxy would exit on socket close, etc. I can include the
parent PID in the audit info. 

So if anyone has already done this or there is some reason for not
choosing this path I'd appreciate comments.

Thx,
Lenny Bruzenak.

-- 
LC (Lenny) Bruzenak
lenny@magitekltd.com

Re: plugin auditing approach question

[Steve Grubb]

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

Re: plugin auditing approach question

[LC Bruzenak]

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