Re: [redhat-lspp] labeled ipsec auditing

[Paul Moore <paul.moore@hp.com>]

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