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