labeled ipsec auditing

labeled ipsec auditing

[Joy Latten]

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?

Regards,
Joy   

Re: labeled ipsec auditing

[Steve Grubb]

On Thursday 05 October 2006 17:23, Joy Latten 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? 

What we need to capture is the changes to configuration that affects the 
access decisions. Klaus may be better person to judge SP vs SA.

> I looked at how Paul implemented netlabel auditing, but 
> was wondering is there any specific info I should audit for
> labeled ipsec?

We need auid and subj of the process that loads the "rules". Is there any 
security relevant data in the rules that you want to log to help get a better 
idea of what is being inserted/deleted?

Thanks,
-Steve

Re: [redhat-lspp] labeled ipsec auditing

[Paul Moore]

Joy Latten 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? 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?

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" ...

-- 
paul moore
linux security @ hp

Re: [redhat-lspp] labeled ipsec auditing

[Klaus Weidner]

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.

-Klaus

Re: [redhat-lspp] labeled ipsec auditing

[Paul Moore]

Klaus Weidner wrote:
> 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.

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.

-- 
paul moore
linux security @ hp

Re: [redhat-lspp] labeled ipsec auditing

[Klaus Weidner]

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.

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?

As always, keep in mind that the system only needs to be capable of
auditing these events, not that these events always need to be
generating. It's fine to keep the audit events off by default.

-Klaus

Re: [redhat-lspp] labeled ipsec auditing

[Joy Latten]

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?

Joy  

Re: labeled ipsec auditing

[Klaus Weidner]

On Tue, Oct 10, 2006 at 06:25:01PM -0500, Joy Latten wrote:
> 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?

I don't really know the logic well enough to give a definitive answer.
The point is that the audit trail should provide enough information to
see changes to the IPSec state that affect MLS.

If you can make a clear distinction between manually and automatically
created ones in the code, it would be okay to have no audit record for
changes to an SA that was added or removed automatically based on the
SPD, as long as changes to the SPD are audited. If it's not clear how to
distinguish them, it's safest to have audit capability for all SA events.

-Klaus

Re: labeled ipsec auditing

[Serge E. Hallyn]

Quoting Joy Latten (latten@austin.ibm.com):
> 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?

Hi Joy,

you didn't quote the part of Klaus' email which I was hoping you'd
answer:

> 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?

-serge

Re: [redhat-lspp] labeled ipsec auditing

[Joy Latten]

On Wed, 2006-10-11 at 08:38 -0500, Serge E. Hallyn wrote:
> Quoting Joy Latten (latten@austin.ibm.com):
> > 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?
> 
> Hi Joy,
> 
> you didn't quote the part of Klaus' email which I was hoping you'd
> answer:
> 
> > 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?

Sorry about that. :-) Ok, I used Eric's kernel and determined the
following. First, it doesn't seem the SPD completely determines the
rules for ipsec related to MLS. I set my spd to have "s2", and the SAs
created by racoon all had "s0-s15:c0.c1023". In fact they get this no
matter what. This does not seem correct behavior to me. I looked at the
code and it seems we are tacking on the mls label of the flow's secid to
our SA's security context. But I could not find where the flow's secid
gets set on output anywhere in xfrm code. I do not understand this.

Ok, next, I removed the policy in my spd, but SAs created by racoon
stayed around. I had to manually flush them to remove them. 

Joy