Message-Id: <1197067820.2488.123.camel@faith.austin.ibm.com>
Date:	Fri, 07 Dec 2007 16:50:20 -0600
From:	Joy Latten <latten@...tin.ibm.com>
To:	Paul Moore <paul.moore@...com>
Cc:	Eric Paris <eparis@...hat.com>, netdev@...r.kernel.org,
	linux-audit@...hat.com
Subject: Re: [PATCH] XFRM: RFC4303 compliant auditing

On Fri, 2007-12-07 at 16:06 -0500, Paul Moore wrote:
> On Friday 07 December 2007 3:52:31 pm Eric Paris wrote:
> > On Fri, 2007-12-07 at 14:57 -0500, Paul Moore wrote:
> > > NOTE: This really is an RFC patch, it compiles and boots but that is
> > > pretty much all I can promise at this point.  I'm posting this patch to
> > > gather feedback from the audit crowd about the continued overloading of
> > > the AUDIT_MAC_IPSEC_EVENT message type - continue to use it or create a
> > > new audit message type?  Of course any other comments people may have are
> > > always welcome.
> >
> > I'm all for continuing to use it, but I feel like the op= strings should
> > probably all get collected up in one place to ease maintenance in the
> > future, might not matter but it's nice to be able to look only on place
> > in the code to find all of the possible op=
> 
> Agreed.  I punted on doing anything here for two main reasons:
> 
> 1. It makes sense to do this in the xfrm_audit_start() function which I 
> couldn't use here without some overhaul ...
> 2. ... I didn't want to overhaul anything if I was going to end up using 
> separate message types.
> 
> If we decide to go with a single audit message type (kinda sounds like it) 
> I'll fix this up in the next version.
> 
> > The one advantage to multiple messages is the ability to exclude and not
> > audit certain things.  How often will these extra messages actually pop
> > out of a system?  Enough that people would likely still care about some
> > of them but decide they don't want others?  I don't know this stuff, so
> > tell me how often would any of these show up?
> 
> Bingo, this is the whole reason why I was wondering about a different message 
> type.  Currently only SAD and SPD changes are audited and only because they 
> effect the security labels that are assigned to packets as they are 
> imported/exported out of the system (look at the LSPP requirements for 
> auditing the import and export of data).  These new audit messages apply to 
> individual packets and/or a particular SA and have nothing to do with 
> security labels, rather they indicate error conditions found during normal 
> IPsec processing.  It would be difficult to think of all of the particular 
> cases where these error conditions but in general I would say that these 
> audit messages should not be common.
> 

Yes, I agree. They should not happen often. Especially compared to LSPP
requirements of auditing whenever SA or SPD entries were added or
deleted, which are common events.

> The only reason for creating a separate audit message type for these packet/SA 
> messages would be to meet a RFC requirement that states that the 
> implementation MUST allow the administrator to enable and disable ESP 
> auditing.  Now, we can probably say we fulfill that requirement regardless, 
> but more message types allow us greater granularity and flexibility ...
> 
Also, there is great possibility of additional messages.
This is for RFC 4303, which is ESP. There are also audit messages
listed for rfc 4301-IPsec architecture and rfc 4302-AH that may 
happen later.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists