From: cpebenito@tresys.com (Christopher J. PeBenito) Date: Tue, 16 Aug 2011 13:43:53 -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> , <4E451F9D.1060807@tresys.com> Message-ID: <4E4AAC59.4040606@tresys.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com On 8/13/2011 4:39 AM, HarryCiao wrote: > Hi Chris, > > > > > > > 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. > > > > Thanks, I understand role_change rule works like type_change rule to > tell userspace app (pam_selinux.so, for example) how to relabel the > role/type of the terminal when the user logins, but what benefit would > we get by doing this? and what problem would we run into if we don't? We would have to hard code the userspace app to always change the role of the terminal. I'm on the fence as to if we really need this. On one hand, in rbacsep, we always want the terminal role to be the same as the role using it, so hard coding seems fine. But we all know how hard coding behaviors can restrict flexibility. > > > 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_tran sition > > > 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. > > > > So, you mean the per-role templates such as xxx_sudo_t and xxx_su_t > would be retained along with specifying meanin gful roles other than > object_r, right? Right. > And how do you feel about above "type_transition_osid" rule to collapse > these per-role template? You mean it is not necessary for us to add such > rule, since per-role templates are to be retained for rbacsep. But for > ubacsep, per-role templates have been collapsed. I am a bit confused. > How had we done that for ubacsep? What I think you're missing is that this issue was solved in ubacsep. So adding rbacsep back in after ubacsep has already been merged means that the hard work of collapsing derived domains is already done, and I don't foresee new problems with them. There are only a few domains that have this issue; I don't think that we need to add more policy features to completely collapse the templates. > BTW, where can I get some reference for ubac and ubacsep? There isn't a specific reference for it. It is almost all implemented in the constraints in the ubac file. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com