Transitivity in role dominance relation

Transitivity in role dominance relation

[Kim Hyung Chan]

[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]

With the well-documented manuals, I'm successfully testing
several access control policies. (Thanks to all contributors :) )

I've been testing role dominance relation. expecially,
the transitivity of role dominance relation.

prof_r > (osg_r, dbg_r) > stud_r

as;

dominance { role prof_r { role osg_r; role dbg_r; } }
dominance { role osg_r { role stud_r; } }
dominance { role dbg_r { role stud_r; } }
# disabled direct relation
#dominance { role prof_r { role stud_r; } }

In the above relation, I guessed that the prof_r role can not inherit
the types of stud_r as seeing below;

login: dilee_u
Password:

Your default context is dilee_u:osg_r:osg_t.
Do you want to choose a different one? [n]y


[1] dilee_u:osg_r:osg_t
[2] dilee_u:dbg_r:dbg_t
[3] dilee_u:prof_r:prof_t
Enter number of choice:

And I also could not get the context of stud_r using the newrole command
after getting the context of osg_r or dbg_r.

Any comments on this problem???

Have a nice day.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Hyung Chan Kim

Security Group, Concurrent System Research Laboratory
Dept. of Information and Communications
Kwangju Institute of Science and Technology (K-JIST)
1 Oryong-dong Buk-ku Gwangju 500-712, Rep. of Korea

Lab. : +82-62-970-2266
Fax : +82-62-970-2204
Mobile : +82-11-9660-4900
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[-- Attachment #2: Type: text/html, Size: 3037 bytes --]

Re: Transitivity in role dominance relation

[Stephen D. Smalley]

> I've been testing role dominance relation. expecially,
> the transitivity of role dominance relation.
> 
> prof_r > (osg_r, dbg_r) > stud_r
> 
> as;
> 
> dominance { role prof_r { role osg_r; role dbg_r; } }
> dominance { role osg_r { role stud_r; } }
> dominance { role dbg_r { role stud_r; } }
> # disabled direct relation
> #dominance { role prof_r { role stud_r; } }
> 
> In the above relation, I guessed that the prof_r role can not inherit
> the types of stud_r as seeing below;

Yes, this is an artifact of the implementation in the policy compiler,
and doesn't seem desirable.  If you were to specify the above as a single
dominance statement, e.g.
dominance { role prof_r { role osg_r { role stud_r; } role dbg_r { role stud_r; 
} } }
, then prof_r would inherit the types of stud_r and every user
authorized for prof_r would also be authorized for stud_r.  Of greater
concern is the fact that the order of the dominance statements affects
the end result; notice what happens if you simply move the dominance
statements for osg_r and dbg_r before the statement for prof_r.  The
compiler should be changed to eliminate this ordering dependency.

As an aside, note that the example policy does not use role dominance,
and some have suggested that it should be eliminated entirely.  Keep in
mind that the RBAC model does not provide any additional security
mechanism; it is merely an abstraction layer to conveniently group
domains into sets for assignment to users.  The real security of the
system is based on the TE model.

> And I also could not get the context of stud_r using the newrole command
> after getting the context of osg_r or dbg_r.

You need to allow the corresponding role transitions and domain transitions
in the policy.  role dominance doesn't implicitly grant such accesses.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.