Tim, w.r.t. different tenants I might be missing something - why should policies remain stored per-user? In general, when the user creates something, wouldn't the user's policies (more like preferences/template) be applied to and saved for the tenant/created elements they're active in? IMHO you can't solve the policy anomalies when you don't know yet whether they'll ever be applied to the same entity or never actually conflict.
FYI: Ehab Al-Shaer (UNCC) is well known in IEEE regarding policies and has formalized policy anomalies and investigated their detection, also in distributed systems. The scenarios in 1) could be solved with priorities and different corrective actions. I'd say an admin rule has a higher priority than the non-admin one, in which case both should be informed about the precedence taken. The cases user-vs-user and admin-vs-admin shouldn't allow to apply conflicting rules on the same entity. Two admins share the responsibility within a tenant/project and rules should be visible to one another. Same for the user group. I wouldn't know how to deal with "hidden" user-specific rules that somehow interfere with and shadow my already applied policies. as of 2) at creation or runtime Either way you'd want a policy anomaly detected at creation, i.e. when a user's rule is applied. Either the new rule's priority is lower and hence shadowed by the higher priority or the new rule's priority is higher and supersedes actions of another. In either case you'd want the anomaly detected and corrective action taken at the time it is applied (Supersede and email the non-admin, report the user which rules shadow/generalize which, etc, etc). The conflicts/status (overruled/active/etc) should be part of the applied rules set. as of 3) role changes my gut feeling was to say that rules keep their priorities, because they've been made by an admin/non-admin at that time. The suddenly-an-admin user could remove the shadowing rules if it bugs the user-rules. my 2 cents, Manuel ________________________________________ From: Tim Hinrichs [thinri...@vmware.com] Sent: Thursday, January 23, 2014 6:57 PM To: OpenStack Development Mailing List (not for usage questions) Subject: [openstack-dev] [neutron] [policy] More conflict resolution Hi all, Today on the Neutron-policy IRC, we ran into some issues that we wanted all your feedback on (and as I was writing this note several more occurred to me). It's the problem of conflict resolution: different policies making different decisions about what to do. We have a conflict resolution scheme for when conflicts arise within a single policy, but we have yet to solve the problem of conflicts arising because different policies make different decisions. The important thing to know is that each policy is attached to a tenant (and a single tenant can have multiple policies). 1) We need conflict resolution for the following scenarios. Suggestions? - Two policies for a single tenant have a conflict. - Two policies for different tenants with different Keystone roles have a conflict. For example, we expect that admin policies should supersede non-admin policies (i.e. that if the admin policy makes a decision to either allow or drop a packet, then the non-admin's policy is ignored; otherwise, the non-admin's policy makes the final decision). Are there other roles we need to think about? - Two policies for different tenants with the same Keystone roles have a conflict. For example, if there are two admins whose policies conflict, which one wins? 2) Do we perform conflict resolution at the time policies are created (i.e. at the API level) or do we resolve conflicts more dynamically at run-time? To me, API-level conflict resolution doesn't seem like a good option. Suppose a non-admin writes a perfectly reasonable policy. Then a month later an admin writes a policy that conflicts with the non-admin policy. There's no way to reject the non-admin's policy at this point (and we can't reject the admin's policy). It seems the best we can do is inform the non-admin (via email?) that her policy has been overruled. But if we do that, it may be possible for a tenant to learn what the admin's policy is--whether that is a security problem or not I don't know. 3) What do we do when roles change, e.g. a non-admin user gets promoted to an admin user or vice versa? And how do we find out about role changes if the users do not log in after their policies have been created? That is, role-changes seem to affect the overall policy that is enforced at any point in time and thus role-changes ought to be factored into policy enforcement. Role-changes make me even more dubious that API-level conflict resolution is a good choice. Hopefully that's a reasonable summary. Others will chime in where not. Thoughts? Thanks, Tim _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
