|
Hi Chris, > Date: Fri, 27 May 2011 10:57:32 -0400 > From: cpebenito@xxxxxxxxxx > To: method@xxxxxxxxxxxxxxx > CC: qingtao.cao@xxxxxxxxxxxxx; sds@xxxxxxxxxxxxx; jmorris@xxxxxxxxx; eparis@xxxxxxxxxxxxxx; selinux@xxxxxxxxxxxxx; dwalsh@xxxxxxxxxx > Subject: Re: v0 Add role attribute support to libsepol > > On 05/27/11 10:23, Joshua Brindle wrote: > > Joshua Brindle wrote: > >> Harry Ciao wrote: > >>> > >>> Comments: > >>> --------- > >>> Add role attribute to SELinux, which aims at replacing the deprecated > >>> role dominance rule. > >> > >> Thanks. This is going to take a bit of time to absorb and most of my > >> cycles are > >> in use at the moment. I'll definitely get around to looking at it though. > >> > > > > I'd also like to solicit feedback from Dan an! d Chris as to how this will > > be used in policy, and as to whether this implementation is suitable. > > > > Dan, Chris, opinions? > > Do we really want to overload the attribute statement for declaring role > attributes? Well, I guess we have to, since the attribute statement would be the only entrypoint to set a role_datum_t.flavor as ROLE_ATTRIB, and the role-types statement would no longer be able to declare roles, since they current syntax does not support to specify if the role is a regular role or a role attribute. BTW, a regular role would be declared by the newly added role-attr statement exactly as the type statement, and the role-types statement would be solely used for setting up role - role attribute association and association between role attributes. > > If I understand the description correctly, it seems reasonable, but will > still run into problems for refpolicy. We want ! to immediately use this > feature for handling chains of run int erfaces. For example, say we have > an admin (admin_r:admin_t) and he can run the foo program (foo_t > domain). The foo program then runs the bar program (bar_t) domain. The > (abbreviated) policy right now would look like this: > > foo.te: > bar_domtrans(foo_t) > > foo.if: > interface foo_run( > type_transition $1 foo_exec_t:process foo_t; > role $2 types foo_t; > bar_run($1,$2) > ) > > The reason we do this is so that the bar_t is added on to the admin_r > role, without adding a direct transition from admin_t to bar_t. But the > above gets messy when the policy writer forgets to put the accompanying > bar_run() call in the foo_run() interface implementation. With role > attributes it would be simplified to: > > foo.te: > role foo_roles types foo_t; > bar_run(foo_t, foo_roles) > > foo.if: > interface foo_run! ( > type_transition $1 foo_exec_t:process foo_t; > roleattribute $2 foo_roles; > ) > > But the problem that I suspect we'll see is what happens the bar_run() > interface also has a role attribute? Extending the above example: > > bar.if: > interface bar_run( > type_transition $1 bar_exec_t:process bar_t; > roleattribute $2 bar_roles; > ) > > When the policy is expanded, you end up getting a roleattribute > statement that has all role attributes in it: > > roleattribute foo_roles bar_roles; > > This should result in bar_roles being a superset of foo_roles. It > doesn't sound like this is being done. There is at least one example of > this case in refpolicy, see rpm_run() and seutil_run_semanage(); caller > runs rpm->rpm_script->semanage->load_policy. > Yep, I've got your point. Many thanks for clarifying your n! eeds so that I would have a better idea of how role attributes are exp ected to be used. While, I have sent out v1 patches, the last one 6/6 patch aims at setting up associations between two role attributes, while the first 5 remains the same as v0. BTW, I also have modified rpm.* and selinuxutil.* to setup a test scenario same as what you have described above, please further refer to the attachment of the 0/6 email of v1 patches. Thanks again! Looking forward to your feedbacks. Best regards, Harry > -- > Chris PeBenito > Tresys Technology, LLC > www.tresys.com | oss.tresys.com > > -- > This message was distributed to subscribers of the selinux mailing list. > If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with > the words "unsubscribe selinux" without quotes as the message. |
