|
Hi Stephen and James, Thanks a lot for all your comments. I've got your points, adding class support to the role_transition rule would eliminate the ambiguity and provide the required flexibility to make use of it in a general manner, I will start from the binary reprensantation of the range_transition rule and how libsepol/checkpolicy handles it. Yes, all policy stuff should be migrated to userspace than in kernel. I will be very glad to try to add all these new "xxx_default <class> <fromsubject/object>" rules after the role_transition rule improvement. Best regards, Harry > Subject: Re: [v2] [SELinux] Discussions about rbacsep > From: jwcart2@xxxxxxxxxxxxx > To: sds@xxxxxxxxxxxxx > CC: qingtao.cao@xxxxxxxxxxxxx; cpebenito@xxxxxxxxxx; selinux@xxxxxxxxxxxxx > Date: Fri, 11 Mar 2011 14:04:20 -0500 > > On Fri, 2011-03-11 at 09:11 -0500, Stephen Smalley wrote: > > 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, > > 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. > > > > Adding the class field and making the role_transition look like other > transition rules seem to me to be the right way to go. > > > 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; > > ... > > > > I like the ide! a, but something like "role_default_label_src" or > "role_label_src" would seem to be more descriptive to me. > > > 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. > > > > -- > James Carter <jwcart2@xxxxxxxxxxxxx> > 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. |
