From: harrytaurus2002@hotmail.com (HarryCiao)
Date: Thu, 11 Aug 2011 07:03:08 +0000
Subject: [refpolicy] Status and discussion about rbacsep
In-Reply-To: <4E318362.4000103@tresys.com>
References: <4E2F0B0D.9050206@tresys.com> <1311707249.11418.19.camel@vortex>,
	<20110727204704.606662e8q76lz3sw@webmail.tuffmail.net>,
	<4E318362.4000103@tresys.com>
Message-ID: <SNT139-W26982C3057CA9DCE774F8FAB220@phx.gbl>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com


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;


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?

Also it seems that you had branched refpolicy to provide the rbacsep 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?)

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?

Thanks,
Harry
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110811/db8909d4/attachment.html