[refpolicy] Status and discussion about rbacsep

[Christopher J. PeBenito]

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