I am auditing when an ipsec policy is added and removed from the Security Policy Database. Should I also add audit when an SA is added and removed? SAs can quickly fill up log since there can be many of them and they also have a lifetime associated with them that can result in continuous renewal. I looked at how Paul implemented netlabel auditing, but was wondering is there any specific info I should audit for labeled ipsec?

On Thu, Oct 05, 2006 at 06:15:44PM -0400, Paul Moore wrote: >Hmm, good question. I'm looking at 5.2.4.4 of the LSPP doc and I see this >paragraph at the end (in part "d"): > >"An LSPP-conformant TOE must only use protocols to export data with security >attributes that provide unambiguous pairings of security attributes and the >information being exported. Further, the ST author must make it clear that the >mechanisms, or devices, used to export data with security attributes cannot be >used to export data without security attributes unless this change in state can >only be done manually and is audited. In addition, the security attributes must >be exported to the same mechanism or device as the information. Also, any change >in the security attributes settings of a device must be audited." > >The sentence that concerns me the most is the following: "Also, any change in >the security attributes settings of a device must be audited". I guess it boils >down if we consider a SA a "device" ... I don't think that there a need to treat all SAs as devices. The requirement is to have audit capability for all changes of device state that affect MLS import/export, for example establishing or deleting an SA with an associated MLS label, or modifying the MLS label of an SA (if that's supported). Any operations on SAs that do not involve an MLS label are out of scope for the "Export of Labeled User Data (FDP_ETC.2)" SFR whose application note you are quoting.

On Mon, Oct 09, 2006 at 03:15:09PM -0400, Paul Moore wrote: > Going back to Joy's original mail I think it was the establishing or deleting of > an SA with SELinux context that we were concerned about (at least that is what I > was concerned about) as that could generate quite a bit of traffic. Based on > your comments above it looks like that is something we need to do. Here's what Joy wrote: > I am auditing when an ipsec policy is added and removed from the > Security Policy Database. Should I also add audit when an SA is > added and removed? If I understand it correctly, SAs can also be added and removed manually, and unless we forbid that admins do that, it would need to be audited.

On Mon, 2006-10-09 at 14:30 -0500, Klaus Weidner wrote: > On Mon, Oct 09, 2006 at 03:15:09PM -0400, Paul Moore wrote: > > Going back to Joy's original mail I think it was the establishing or deleting of > > an SA with SELinux context that we were concerned about (at least that is what I > > was concerned about) as that could generate quite a bit of traffic. Based on > > your comments above it looks like that is something we need to do. > > Here's what Joy wrote: > > > I am auditing when an ipsec policy is added and removed from the > > Security Policy Database. Should I also add audit when an SA is > > added and removed? > > If I understand it correctly, SAs can also be added and removed manually, > and unless we forbid that admins do that, it would need to be audited. > Then do I only want to audit when an SA or SPD is manually added or deleted? Or just audit them regardless?

If the SPD completely determines the rules for ipsec related to MLS, it would not be necessary to audit the individual additions and deletions, but I'm not convinced that's the case. Does modifying the SPD automatically tear down any currently active SAs that do not match the updated policy?