From: harrytaurus2002@hotmail.com (HarryCiao) Date: Sat, 13 Aug 2011 08:39:19 +0000 Subject: [refpolicy] Status and discussion about rbacsep In-Reply-To: <4E451F9D.1060807@tresys.com> 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: To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com 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? > > 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. > So, you mean the per-role templates such as xxx_sudo_t and xxx_su_t would be retained along with specifying meaningful roles other than object_r, 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? BTW, where can I get some reference for ubac and ubacsep? Many thanks for your comments. Best regards, Harry > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110813/0aeb3a61/attachment.html