On Tue, Jul 29, 2008 at 04:15:44PM +0900, KaiGai Kohei wrote:
> KaiGai Kohei wrote:
> > [2/3] thread-context-checkpolicy.1.patch
> > This patch add a new statement of TYPEDOMINATE for policy language.
> >
> > TYPEDOMINATE <parent type> <chile type> [, <child type> ...] ;
> >
> > It defines expilct hierarchical relationship between two types.
> > Existing name based hierarchy is dealt as TYPEDOMINATE is described
> > implicitly.
>
> I reconsidered that the statement should be replaced as follows,
> because "DOMINATE" is an associated term with MLS and roles/users
> also have name based hierarchy ideas now.
>
> HIERARCHY <parent type> TYPES <child type> [, <child type> ...];
> HIERARCHY <parent role> ROLES <child role> [, <child role> ...];
> HIERARCHY <parent user> USERS <child user> [, <child user> ...];
>
I agree that TYPEDOMINATE is not a good choice. In dominance, you're
saying "whatever privileges x, y, & z have, give me those too."
I like to think of it as the parent type "circumscribing" or limiting
its children -- the parent draws a line in the sand and says "<child>,
you can grant yourself whatever permissions you want (hopefully no more
than you need), but whatever you do, don't cross this line!" The terms
used to should make that obvious. "Circumscribe" is fun to say, but
awkward to type, so how about:
TYPELIMIT <parent type> { <child type> [, <child type> ...] } ;
ROLELIMIT <parent role> { <child role> [, <child role> ...] } ;
It would read better to say:
TYPE <parent type> LIMITS { <child type> [, <child type> ...] } ;
ROLE <parent role> LIMITS { <child role> [, <child role> ...] } ;
but that conflicts with existing syntax. Hence the patterning after
attributes and aliasing.
I'm not sure what hierarchy for users implies, or why it's needed. If we
have adequate support for hierarchy/dominance in roles, doesn't that
suffice for users? After all, users can't do anything their roles don't
permit them to. I guess I see users as a slightly different case because
they are going to be more per-system than roles or types, so if you
don't trust system administrators to set a user's roles correctly, you
shouldn't make them a sysadmin. Or am I missing something?
--
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.
