Replace Chinese punctuation with English punctuation
Curly quotes(Chinese punctuation) usually input from Chinese input method. When read from english context, it makes some confusion. Change-Id: I555d5cd51457984050a8822e777b4e82e15c5d99
This commit is contained in:
parent
9b59c4eead
commit
03ef3321e1
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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).
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue