On Fri, 2011-03-11 at 15:20 +0800, Harry Ciao wrote: > Hi Stephen and Chris, > > I have fixed the semantics of the role_transtion rule for the newly created files or dirs objects same as that for the process class. Since class-specific role_transition rules would be handled after TE rules, we could make use of checking if (newcontext.type == roletr->type) and (scontext->role == roletr->role) before setting newcontext.role = roletr->new_role; > > Then in the refpolicy we could adopt Stephen's suggestion for the role_transition rule such as: > role_transition sysadm_r user_home_t sysadm_r; > > But I think we could omit class in above rule, since such role_transition semantics only takes place when filedir == true, that is, when the new object is of file or dir class. If we omit the class, then the above statement has two possible interpretations: 1) When a process in sysadm_r executes a program labeled user_home_t, the process transitions to sysadm_r (no effect in this case, but it would have an effect if the new role were something other than the old one), or 2) When a process creates a file in a directory labeled user_home_t, then the new file will be labeled with sysadm_r. I'm concerned about that ambiguity in the meaning of the rule if we don't explicitly specify the class. Also, by not specifying the class, you keep us from re-using this mechanism for other object classes in a general manner. I don't think that it would be too hard to add an optional class field to the role_transition statements; you can follow the model of what we did for range_transitions when we added the class field to it. That does require a policy version bump and an updated checkpolicy/libsepol. What would also be desirable would be a new policy construct that would allow us to specify the default labeling behavior for each component of the security context on a per-class basis, e.g. role_default file fromtarget; role_default process fromsource; user_default socket fromsource; ... That would eliminate the need for the security_is_*_class functions and the special handling in the kernel for particular classes, and migrate all of this logic into the policy. That however may be more than you are willing to take on at the present time. -- Stephen Smalley National Security Agency -- 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.
