Hi Manuel, Responses inline. Thanks for the feedback!
----- Original Message ----- | From: "Manuel Stein (Manuel)" <manuel.st...@alcatel-lucent.com> | To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> | Sent: Friday, January 24, 2014 2:03:43 AM | Subject: Re: [openstack-dev] More conflict resolution | | 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. Each policy has a src and destination group to which it applies. Groups include apps, VMs, logical ports, or whatever. Group membership can change. Because groups are dynamic it may be that at the time the policy is written there are no conflicts but that as elements are added to the groups, conflicts arise. And since each policy only applies to some packets, there can be conflicts for some communications and not others. | | 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. Thanks for the pointer. I quickly perused his publication list and will return to it when I have more time to browse. | | 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. Priorities seem like the right solution for admin-tenant conflicts. Are there any other roles that should have priorities? I think that disallowing conflicting policies is a bit difficult, esp in the tenant-tenant case b/c the two tenants may not know each other. It might be disconcerting for a tenant to have her policy rejected b/c someone she didn't know wrote a policy she's not allowed to see that may potentially conflict with her policy at some point in the future. An alternative to disallowing conflicting policies from is to combine the policies of the same priority into a single policy (conceptually) and then apply the conflict-resolution scheme for that single policy. Thoughts? | | 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. What if the rules only conflict sometimes (e.g. for some packets), e.g. one policy says to ALLOW packets with dest port 80 and another rule says to DROP packets with src port 80. For most packets, there's no conflict, but if the dest-port is 80 and the src-port is 80, then there's a conflict. So (a) it's not as simple as marking a rule as overruled/active/etc., (b) computationally it may be non-trivial to identify rules that sometimes conflict, and (c) the users writing the policies may know that the packets that cause conflicts will never appear in the network. | | 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. Role changes are complicated for 2 reasons: (i) we need to have a way of finding out about them and (ii) once we have the information we need to decide what to do with it. Any thoughts on how to accomplish (i)? As for (ii), I worry about leaving rule priorities as they were before the role change because the whole purpose of a role change is to change someone's rights. If someone was an admin and were demoted for questionable behavior, leaving their policies in the admin priority seems like a mistake. At the same time, re-prioritizing the rules for role changes could cause drastic behavioral changes in the network. If a regular user's policies are all suddenly promoted to admin priority, no one will be able to predict how the policy changes will affect the network. Demoting admin rules to non-admin priority has a similar effect. Hmmm... leaving the priorities the same seems problematic, but changing the priorities seems problematic too; not sure what to do here. Tim | | 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 | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=GCQOsyh5WyZr4Lx2t%2Bs5Kt6S9fWkBV9dfeL%2B1xUUBag%3D%0A&s=c06f67fbd826026f4abc79fda10240d25bd756e237f4c121a43e06de8cdfc5e1 | | _______________________________________________ | OpenStack-dev mailing list | OpenStack-dev@lists.openstack.org | https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=GCQOsyh5WyZr4Lx2t%2Bs5Kt6S9fWkBV9dfeL%2B1xUUBag%3D%0A&s=c06f67fbd826026f4abc79fda10240d25bd756e237f4c121a43e06de8cdfc5e1 | _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
