On Thu, 2005-06-23 at 13:54 -0400, Stephen Smalley wrote:
> On Thu, 2005-06-23 at 12:17 -0400, Joshua Brindle wrote:
> > The attached patch disallows * and ~ in certain kinds of rules, the list
> > of where they are allowed and where they are not follows. I'm very
> > willing to discuss any ideas or arguments as to why these should or
> > shouldn't be in the list they are in.
> > 
> > 
> > * and ~ allowed:
> > range_trans (I was hoping TCS had an opinion on this)
> > neverallow, dontaudit, auditallow
> > 
> > 
> > * and ~ not allowed:
> > allow rules
> > type_transition, type_member, type_change
> > role declarations (to add types to a role)
> > role transitions
> 
> The patch only appears to alter their use in type sets, nothing else
> (e.g. they can still be used for permission sets and role sets).  Is
> that your intent?
> 
This is definitely up for debate. The major problems with type sets was
that using * and ~ in types would add rules when types were added, even
without assigning attributes or writing explicit rules. Permissions are
something different because they are mostly static and it's fairly well
known what you are saying you want when you use * for permissions.

Roles are interesting and I hadn't really thought about them. The
attached patch disallows * and ~ in role transitions, role allows and
user declarations in the role sets.

> For type sets, I'd favor greater consistency, e.g. not allow their use
> in any type set except neverallow rules and only in them because they
> are used to catch ill-formed policies.  Otherwise, type set exclusion
> (e.g. domain -foo) is always preferable to set complement (e.g. ~foo),
> as the latter will include unrelated types (e.g. file types) that are
> not possible in that field, and a type attribute like domain or
> file_type should always be used rather than a * for the same reason.
> Looks like the FC4 strict and targeted policies are clean in this
> respect, not sure about everything in the example policy.

Ok, I wasn't really sure if * or ~ would be useful in range_trans so I
left that for an MLS user to say something. The attached patch disallows
it.

I agree that neverallow has very legitimate reasons for * but dontaudit
and auditallow are a little less clear. Perhaps auditallow should allow
*, it's conceivable that someone would want to audit all access to an
object (though in the current policies and reference policy * would have
the same net effect as domain with fewer avtab entries). This may not be
the case for all policies though. The attached patch disallows it in all
rule types but neverallow. 

I forgot to mention constraints, which currently allow * and ~, any
thoughts on this?


Joshua