On Mon, Mar 30, 2009 at 12:51:48PM -0400, Stephen Smalley wrote: > On Fri, 2009-03-27 at 17:09 -0500, Nicolas Williams wrote: > > On Fri, Mar 27, 2009 at 09:22:42AM -0400, Stephen Smalley wrote: > > > On Fri, 2009-03-27 at 08:55 -0400, Stephen Smalley wrote: > > > > You can't represent Type Enforcement via MLS/BLP; TE is strictly more > > > > expressive than BLP, not the other way around. It also has no inherent > > > > notion of dominance; the access matrix is explicitly defined and may > > > > include intransitive relationships, which are required for integrity > > > > goals and guaranteed invocation. > > > > I thought that MLS compartment -> DTE type. Is that not the case? I > > realize that DTE does not have an inherent notion of dominance, but for > > _documents_ (as opposed to operating system- or application-specific > > files like /etc/shadow) there surely must be a way to establish > > dominance, no? That seems important to me. > > No, there just needs to be a way to establish authorization. The > internal logic for determining whether data of a given label is allowed > to transit over a network interface of a given label is policy-specific > and shouldn't be limited to the dominance relation. It can just be > represented as a permission check on a label pair for a given object > class, and then the security policy logic can internally decide yes/no > on that permission based on any combination of the dominance relation, > the TE access matrix, or any other policy constraints.
OK, good -- that's a local-to-end-points consideration, so we can keep the use of DTE at the end-to-end application layer and CALIPSO at the IP layer compatible.
