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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
