Re: [PATCH] XFRM: RFC4303 compliant auditing
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.
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 ...
--
paul moore
linux security @ hp