diff --git a/specs/kilo/datalog-ng.rst b/specs/kilo/datalog-ng.rst index 85e2afa..27c3b9b 100644 --- a/specs/kilo/datalog-ng.rst +++ b/specs/kilo/datalog-ng.rst @@ -46,8 +46,8 @@ interpreter, and/or a compiler. See [3]_ for more information on the benefits of formally defining a grammar. Change #1: Table Referencing -[1]_ says: “Conceptually, Datalog describes policy in terms of a collection -of tables.” Tables are a simple way of conveying information, and lend +[1]_ says: "Conceptually, Datalog describes policy in terms of a collection +of tables." Tables are a simple way of conveying information, and lend themselves to querying, editing, and reporting. Policy rules can be thought of as how input from one or more tables can be transformed into output in one or more tables. Tables are full-fledged objects, so this enables us to not only @@ -87,7 +87,7 @@ queries are NOT safe: :: foo(X, Y) :- rel1(X) Change #6: Grammatical Improvements -Datalog is powerful, but somewhat hard to use. A set of “syntactical sugar” +Datalog is powerful, but somewhat hard to use. A set of "syntactical sugar" will be defined to make Datalog easier to use, especially for the native Python developer. @@ -113,7 +113,7 @@ there are other types of policy rules: • Goal policies • Utility functions • Promises -[6]_ covers the first two, and [7]_ is the latest of Mark’s publications on +[6]_ covers the first two, and [7]_ is the latest of Mark's publications on promise theory. All three of the above are different in form and function than ECA and CA policy rules. Datalog-ng can model the intent of most of these forms of policy rules, which is what is needed in Congress – the ability to @@ -143,8 +143,8 @@ flow of control to perform the task. First-order logic is a formal system of logic in which each statement consists of a subject and a predicate. A predicate can only refer to a single subject. Sentences are combined and manipulated using the same rules as those used in Boolean algebra. Two -quantifiers exist: “for all” and “for some” (higher-order logics have -additional quantifiers, such as “for every property of an object”). +quantifiers exist: "for all" and "for some" (higher-order logics have +additional quantifiers, such as "for every property of an object"). Datalog is thus more powerful than simple propositional logic, but not as powerful as first-order logic. However, it provides a combination of power and @@ -185,7 +185,7 @@ N/A Security impact --------------- -Policy can contain the proverbial “keys to the kingdom”. So, if someone +Policy can contain the proverbial "keys to the kingdom". So, if someone hacks their way into the system and can start issuing policies, game over. Therefore, some type of access control should be used with policy-based systems. @@ -297,10 +297,10 @@ developers from themselves. :-) Change #6: Grammatical Improvements A set of grammatical improvements will be defined to simplify the use of Datalog-ng, and especially to make its syntax friendlier to Python developers. -Examples include more recognizable comments (e.g., familiar “//” or -“/*..*/” instead of the native Datalog ‘%’), the ability to use single +Examples include more recognizable comments (e.g., familiar "//" or +"/*..*/" instead of the native Datalog '%'), the ability to use single and/or double quotes, and English equivalents to some commands -(e.g., ‘!’ or ‘NOT’ or ‘not’). +(e.g., '!' or 'NOT' or 'not'). Dependencies diff --git a/specs/kilo/dse-control-bus.rst b/specs/kilo/dse-control-bus.rst index 6cbc8a7..d662b08 100644 --- a/specs/kilo/dse-control-bus.rst +++ b/specs/kilo/dse-control-bus.rst @@ -16,7 +16,7 @@ broadcast mechanism is used for this purpose. While effective, these broadcasts are inefficient, and complicate debugging. Instead of using the exiting broadcast-based discovery mechanism, nodes on -the DSE should publish events on a well-known "collections registry,” +the DSE should publish events on a well-known "collections registry," that every node subscribes to. @@ -32,15 +32,15 @@ Proposed change =============== * All instances of deepSix will subscribe to a well-known table, - which we will refer to as the ‘collection registry’. + which we will refer to as the 'collection registry'. * When the data indexes exposed by a deepSix instance changes (including instance startup), the instance will publish an update to the collection registry. -* Each deepsix instance will maintain a list of it’s data_indexes that it has - a desired subscription for. The instance will do a lookup in it’s local +* Each deepsix instance will maintain a list of it's data_indexes that it has + a desired subscription for. The instance will do a lookup in it's local copy of the collection registry to find associated endpoints to send subscription requests to. As changes occur to the collection registry, - each instance will re-evaluate it’s own subscriptions against these + each instance will re-evaluate it's own subscriptions against these updates. * There is a collection registry per instance of the DSE. In a hierarchical DSE, there could be multiple registries. diff --git a/specs/kilo/horizon-policy-abstraction.rst b/specs/kilo/horizon-policy-abstraction.rst index 5007142..43bbcbd 100644 --- a/specs/kilo/horizon-policy-abstraction.rst +++ b/specs/kilo/horizon-policy-abstraction.rst @@ -35,14 +35,14 @@ Policies in Congress can be expressed by BNF as below. :: - Congress Policy ::= violation condition, “do” action for violation + Congress Policy ::= violation condition, "do" action for violation So, policy abstraction is to abstract violation state and corresponding action to make the policy more intuitive and easy to use. By analyzing typical scenarios, violation mainly can be divided into two parts. -One is the constraint of objects’ attributes, and another is the constraint -of relationship between several objects’ attributes. +One is the constraint of objects' attributes, and another is the constraint +of relationship between several objects' attributes. All the objects and constraints are not just a simple set of data source tables, but they can be divided into some categories according to their functions and relations. So users just need to choose objects they care about @@ -53,7 +53,7 @@ The violation condition can be expressed by BNF as below. :: violation condition ::=object attribute constraint (value | object attribute) - object attribute::=object “.” attribute + object attribute::=object "." attribute For any violation state, congress will take some actions, such as monitoring, proactive and reactive. Though congress has just realized monitor violation, @@ -65,15 +65,15 @@ The action for violation state can be expressed by BNF as below. :: - action ::= (“monitor”| “proactive”| “reactive”) data + action ::= ("monitor"| "proactive"| "reactive") data So policies in Congress can be abstracted into "name", "objects", "violation condition", "action" and "data". -Among these, element “name” defines a marker of a policy, which is used to +Among these, element "name" defines a marker of a policy, which is used to be a unique identification for a policy. -Element “objects” defines all objects which are concerned by this policy. +Element "objects" defines all objects which are concerned by this policy. They are not just simple display of data source tables, but a organized set which contains the relationship between different objects, such as, "servers", "networks", "hosts", "subnets", etc. @@ -82,16 +82,16 @@ a attribute of other objects, such as, "servers", "networks". Another example is users could choose "servers" and "networks" without caring about what put them together ("ports", actually). -Element “violation condition” defines the state of objects' attributes +Element "violation condition" defines the state of objects' attributes which can produce violation, and the constraint will include comparison, arithmetic and some predefined relationship/functions, such as, "same_group". -Element “action” defines the action needs to take for this policy, +Element "action" defines the action needs to take for this policy, and actions will include "proactive", "monitoring" and some specific actions, such as, "remove", "delete". All these actions depend on the ability of underlying components. -Element “data” defines the information gotten or needed when executing the +Element "data" defines the information gotten or needed when executing the action, for example, when monitoring a servers violation, users can define "data" as servers' name to be a return parameters. @@ -118,7 +118,7 @@ owned by someone in the same group as the VM. For this example, users care about "servers" and "networks", so users will choose these two objects from a drop-down list. After users decide the objects, corresponding optional violation state will -be decided, which will include these two objects’ attributes and some +be decided, which will include these two objects' attributes and some predefined relationship, so users can choose "not same_group" and choose who are not in the same group. All the choices will be show as drop-down lists, too. And users need to choose the action and data for this violation. diff --git a/specs/kilo/refactor-datasource-driver-framework.rst b/specs/kilo/refactor-datasource-driver-framework.rst index 9238076..6c345c4 100644 --- a/specs/kilo/refactor-datasource-driver-framework.rst +++ b/specs/kilo/refactor-datasource-driver-framework.rst @@ -55,7 +55,7 @@ Example: error(vm) :- nova:virtual_machine(vm), ids:ip_packet(src_ip, dst_ip), - neutron:port(vm, src_ip), //finds out the port that has the VM’s IP + neutron:port(vm, src_ip), //finds out the port that has the VM's IP ids:ip_blacklist(dst_ip). diff --git a/specs/liberty/compromised-vm.rst b/specs/liberty/compromised-vm.rst index 0788239..a8b534a 100644 --- a/specs/liberty/compromised-vm.rst +++ b/specs/liberty/compromised-vm.rst @@ -60,17 +60,17 @@ Policy error(vm) :- nova:virtual_machine(vm), ids:ip_packet(src_ip, dst_ip), - neutron:port(vm, src_ip), //finds out the port that has the VM’s IP + neutron:port(vm, src_ip), //finds out the port that has the VM's IP ids:ip_blacklist(dst_ip). Policy actions ----------------- -* Monitoring: report/log the incident including the VM’s IP address, external +* Monitoring: report/log the incident including the VM's IP address, external IP, etc. * Reactive: Invoke the nova API to add the VM to IDS security group restricting access to make changes. Invoke neutron to block all traffic to/from the - VM’s IP address. Alternatives are to restart the VM on a nova IDS + VM's IP address. Alternatives are to restart the VM on a nova IDS schedule filter (limiting traffic chaos while maintaining the ability to access the VM) and/or a no route network or removing the VM network interface(s). diff --git a/specs/liberty/horizon-policy-abstraction.rst b/specs/liberty/horizon-policy-abstraction.rst index 4d7c3b6..f5bc810 100644 --- a/specs/liberty/horizon-policy-abstraction.rst +++ b/specs/liberty/horizon-policy-abstraction.rst @@ -35,14 +35,14 @@ Policies in Congress can be expressed by BNF as below. :: - Congress Policy ::= violation-condition, “do” action for violation + Congress Policy ::= violation-condition, "do" action for violation So, policy abstraction is to abstract violation state and corresponding action to make the policy more intuitive and easy to use. By analyzing typical scenarios, violation mainly can be divided into two parts. -One is the constraint of objects’ attributes, and another is the constraint -of relationship between several objects’ attributes. +One is the constraint of objects' attributes, and another is the constraint +of relationship between several objects' attributes. All the objects and constraints are not just a simple set of data source tables, but they can be divided into some categories according to their @@ -54,7 +54,7 @@ The violation-condition can be expressed by BNF as below. :: violation-condition ::=object attribute constraint (value | object-attribute) - object-attribute::=object “.” attribute + object-attribute::=object "." attribute For any violation state, congress will take some actions, such as monitoring, proactive and reactive. Of course, there may be more than one action defined to @@ -67,15 +67,15 @@ The action for violation state can be expressed by BNF as below. :: - action ::= (“monitoring”| “proactive”| “reactive action”) data + action ::= ("monitoring"| "proactive"| "reactive action") data So policies in Congress can be abstracted into "name", "objects", "violation-condition", "action" and "data". -Among these, element “name” defines a marker of a policy, which is used to +Among these, element "name" defines a marker of a policy, which is used to be a unique identification for a policy. -Element “objects” defines all objects which are concerned by this policy. +Element "objects" defines all objects which are concerned by this policy. They are not just simple display of data source tables, but a organized set which contains the relationship between different tables and objects, such as, "servers", "networks", "hosts", "subnets", etc. @@ -84,16 +84,16 @@ a attribute of other objects, such as, "servers", "networks". Another example is users could choose "servers" and "networks" without caring about what put them together ("ports", actually). -Element “violation-condition” defines the state of objects' attributes +Element "violation-condition" defines the state of objects' attributes which can produce violation, and the constraint will include comparison, arithmetic and some predefined relationship/functions, such as, "same_group". -Element “action” defines the action needs to take for this policy, +Element "action" defines the action needs to take for this policy, and actions will include "proactive", "monitoring" and some specific actions, such as, "create", "pause". All these actions depend on the ability of underlying components. -Element “data” defines the information gotten or needed when executing the +Element "data" defines the information gotten or needed when executing the action, for example, when monitoring a servers violation, users can define "data" as servers' name to be a return parameters. diff --git a/specs/newton/template.rst b/specs/newton/template.rst index 31bbe24..8c693e5 100644 --- a/specs/newton/template.rst +++ b/specs/newton/template.rst @@ -82,7 +82,7 @@ Example: error(vm) :- nova:virtual_machine(vm), ids:ip_packet(src_ip, dst_ip), - neutron:port(vm, src_ip), //finds out the port that has the VM’s IP + neutron:port(vm, src_ip), //finds out the port that has the VM's IP ids:ip_blacklist(dst_ip). diff --git a/specs/pike/policy-library.rst b/specs/pike/policy-library.rst index d632962..b619242 100644 --- a/specs/pike/policy-library.rst +++ b/specs/pike/policy-library.rst @@ -105,7 +105,7 @@ policy library). #. Administrator peruses policies in library #. Administrator clicks on an interesting policy, which brings up a textbox (or more sophisticated policy editor) to customize. - #. Administrator clicks on a ‘Create’ button that creates that policy. + #. Administrator clicks on a 'Create' button that creates that policy. Below are the specific functionalities needed to support these workflows. diff --git a/specs/template.rst b/specs/template.rst index 31bbe24..8c693e5 100644 --- a/specs/template.rst +++ b/specs/template.rst @@ -82,7 +82,7 @@ Example: error(vm) :- nova:virtual_machine(vm), ids:ip_packet(src_ip, dst_ip), - neutron:port(vm, src_ip), //finds out the port that has the VM’s IP + neutron:port(vm, src_ip), //finds out the port that has the VM's IP ids:ip_blacklist(dst_ip).