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. > Also, in the case of SELinux and FMAC, the security context is more than > just a domain/type; it contains all of the security attributes relevant > to the security policy model, which in the case of the example security > server includes a user identity, a role, a domain/type, and a MLS range > (optionally just a single MLS level in the degenerate case where low == > high). But as far as the protocols are concerned, the entire security > context is just an opaque string. My RPCSEC_GSSv3 proposal allows the client to make assertions about the local process credentials of the process on whose behalf the client is acting. Things like identity, group memberships, privileges, audit context, etcetera. (Obviously the server has to evaluate what weight to give those assertions given the client's and the user's authenticated identities.) Nico -- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
