From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Fri, 12 Aug 2011 08:42:05 -0400 Subject: [refpolicy] Status and discussion about rbacsep In-Reply-To: References: <4E2F0B0D.9050206@tresys.com> <1311707249.11418.19.camel@vortex>, <20110727204704.606662e8q76lz3sw@webmail.tuffmail.net>, <4E318362.4000103@tresys.com> Message-ID: <4E451F9D.1060807@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 08/11/11 03:03, HarryCiao wrote: > Hi Chris, > > These days I read through your discussions about rbacsep way back to > 2008. At that time you'd pointed out a todo list for full rbac > separation support: > > 1. Kernel's recognition of role_transition rule for non process classes; > > 2. Role attribute support as in below rbacsep constrain: > > constrain { dir file ... } { getattr read write .... } > r1 == r2 > or r1 == system_r > or r2 == object_r > or r1 == rbac_subj_role_file_exempt > or r2 == rbac_obj_role_file_exempt > or t1 == rbac_subj_type_file_exempt > or t2 == rbac_obj_type_file_exempt; > > 3. Add a new "role_change" rule and modify login/newrole program to > change controlling terminal's role according to that of user; > > 4. Add a new "role_member" rule for polyinstantiation support; > > 5. genhomedircon updated for role; > *6. Move the policy to initialize newcontext from security_compute_sid() > in kernel up to refpolicy, by introducing new rules such as(suggested by > Stephen, not directly related with rbacsep): > > role_default {process socket ...} fromsource; > type_default {process socket ...} fromsource; > role_default {file dir ...} fromtarget; > type_default {file dir ...} fromtarget; I don't remember this one. > Here are my comments and questions: > > As for 1, it has been done since we have added the class support to the > role_transition rule. Refpolicy could have whatever needed rules added > to transition the role of files/dirs from object_r; > > As for 2, it has been done too since we have added the role attribute > support; > > As for 3 & 4, it won't be difficult for us to add these two new rules, > but I have not understand clear yet the influence and meanings of the > role_change rule, could you explain it a bit more? Well we've had role_change rules since the ancient times. Its purpose is to inform userspace apps how to relabel a user's terminal when they change roles. > Also it seems that you had branched refpolicy to provide the rbac sep > constrain and collapse per-role templates such as xxx_sudo_t to > sudo_t(where can I get it?) but further run into type_transition > conflicts when sudo_t needs to transition back to user's domain: > > type_transition sudo_t shell_exec_t:process auditadm_t; > type_transition sudo_t shell_exec_t:process secadm_t; > type_transition sudo_t shell_exec_t:process staff_t; > type_transition sudo_t shell_exec_t:process sysadm_t; > type_transition sudo_t shell_exec_t:process user_t; > > You've mentioned since we can't make sudo application SELinux-aware due > to their vast differences, we would have to fall back on the per-role > template of xxx_sudo_t. (Actually this is the end of your rbacsep > effort, right?) Correct, thats where we stopped. > Would it be possible to tackle such condition by introducing a new > "type_transition_osid" rule? For example, > > type_transition_osid sudo_t shell_exec_t : process; > > And in security_compute_sid(), for AVTAB_TRANSITION rules we would > search for type_transition_osid rules aside from type_transition rules > for the process class. If a matching type_transition_osid rule is found, > then newcontext->type would be set to the type from tsec->osid. > > If it makes sense, then what else works may have been required aside > from it and the above todo list for full rbacsep support? We don't need to add anything special; we have the same problem with ubacsep, and solved it by retaining the per-role domains, eg. user_su_t, sysadm_sudo_t, etc. When we restart, it don't think it will be nearly as much work, since all of the collapsing was done for ubacsep. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com