rename terminology "not flag" to "negate option"

This commit is contained in:
root
2024-08-22 08:28:33 +00:00
parent e538f5bb52
commit 72cf89723d
23 changed files with 183 additions and 183 deletions

View File

@@ -861,7 +861,7 @@ int maat_scan_not_logic(struct maat *instance, int table_id,
size_t *n_hit_result, struct maat_state *state);
```
If the rule configuration contains NOT-conditions, this interface needs to be called to activate the calculation of rule_id involving NOT-conditions. This means that other scanning interfaces will not activate NOT-conditions except for calling this interface. When to call this interface is determined by the caller. For example, on a session, four packets were scanned with maat_scan_string and three rule_id were hit. The NOT-condition was expected to be activated, so this interface was called and two new rule_id were hit.
If the rule configuration contains negate-conditions, this interface needs to be called to activate the calculation of rule_id involving negate-conditions. This means that other scanning interfaces will not activate negate-conditions except for calling this interface. When to call this interface is determined by the caller. For example, on a session, four packets were scanned with maat_scan_string and three rule_id were hit. The negate-condition was expected to be activated, so this interface was called and two new rule_id were hit.
Since this interface only activates non-conditions and does not call the underlying scanning engine to perform actual scanning tasks, there is no data to be scanned.

View File

@@ -60,7 +60,7 @@ Table schema is stored in a json file(such as table_info.conf), which is loaded
"custom": {
"group_id":1,
"rule_id":2,
"not_flag":4,
"negate_option":4,
"attribute_name":5,
"condition_index":6
}

View File

@@ -124,7 +124,7 @@ rule(rule) = condition1 & !condition2
The JSON configuration for the logical `OR` can be referenced at [unit_test Json configuration](../test/maat_json.json) with rule_id=145.
The group_name: "123_IP_group" is a NOT condition of this rule.
The group_name: "123_IP_group" is a negate condition of this rule.
## Group exclude

View File

@@ -256,7 +256,7 @@ Describe the relationship between group and rule.
| **group_ids** | VARCHAR(256) | group ids are separated by commas(g1,g2,g3) |
| **rule_id** | LONG LONG | rule id |
| **is_valid** | INT | 0(invalid), 1(valid) |
| **not_flag** | INT | logical 'NOT', identify a NOT condition, 0(no) 1(yes) |
| **negate_option** | INT | logical 'NOT', identify a negate condition, 0(no) 1(yes) |
| **attribute** | VARCHAR2(256) | attribute name, NOT NULL |
| **Nth_condition** | INT | the condition seq in (conjunctive normal form)CNF, from 0 to 7. groups with the same condition ID are logical 'OR' |
@@ -443,7 +443,7 @@ In addition to the rule table, there is also the group2rule table in the table s
**Note:** This will involve the terminology of [condition](./terminology.md#condition).
1. For expressions without NOT-conditions, returning the matched rule_id:
1. For expressions without negate-conditions, returning the matched rule_id:
* rule1 = condition1 & condition2 = {attribute1, g1} & {attribute2, g2}
@@ -451,7 +451,7 @@ In addition to the rule table, there is also the group2rule table in the table s
Given the matched attribute_id and group_id, all matching rule_ids can be provided. For example, if scanning attribute1 matches g2 and attribute2 matches g3, rule_runtime will return the matched rule_id 2.
2. For expressions with NOT-conditions, returning the matched rule_id:
2. For expressions with negate-conditions, returning the matched rule_id:
* rule3 = condition1 & !condition2 = {attribute1, g1} & !{attribute2, g2}
@@ -459,7 +459,7 @@ In addition to the rule table, there is also the group2rule table in the table s
If scanning attribute1 matches g1 and attribute2 matches g3, rule_runtime will return the matched rule_id 4.
3. If a rule_id is matched, the full hit path can be obtained: **item_id -> group_id ->** {super_group_id} -> condition{**attribute_id, not_flag, condition_index} -> rule_id**. If the matched group is not referenced by a rule, a half hit path can be obtained: **item_id -> group_id** -> {super_group_id}.
3. If a rule_id is matched, the full hit path can be obtained: **item_id -> group_id ->** {super_group_id} -> condition{**attribute_id, negate_option, condition_index} -> rule_id**. If the matched group is not referenced by a rule, a half hit path can be obtained: **item_id -> group_id** -> {super_group_id}.
4. Getting the matched group_ids and the count of hit groups.
@@ -473,9 +473,9 @@ Rule runtime loads the rule table and group2rule table configurations into memor
1. All condition_ids under the same rule are used to construct AND expressions, and all rule AND expressions are used to build a bool_matcher.
2. For not_flag=0 (conditions), a `condition_id hash` is built, key:{group_id, attribute_id, not_flag}, value:condition_id.
2. For negate_option=0 (conditions), a `condition_id hash` is built, key:{group_id, attribute_id, negate_option}, value:condition_id.
3. For not_flag=1 (NOT-conditions), a `NOT_condition_id hash` is built, key:{group_id, attribute_id, not_flag}, value:condition_id.
3. For negate_option=1 (negate-conditions), a `NOT_condition_id hash` is built, key:{group_id, attribute_id, negate_option}, value:condition_id.
* **Data Plane**
@@ -493,10 +493,10 @@ On the data plane, services are provided externally through the maat API, primar
* Use the hit condition_ids to determine if there are any hit rule_ids. If there are, populate the half-hit path which will become full-hit path.
2. **maat_scan_not_logic**: This interface is used to activate NOT-condition logic.
2. **maat_scan_not_logic**: This interface is used to activate negate-condition logic.
* Traverse the `NOT_condition_group` of `attribute_id`. For each `group_id`, form a key `{group_id, attribute_id, 1}` to obtain the `NOT_condition_id`. If it is in the `exclude condition_ids` set, ignore it; otherwise, add it to the `all hit condition_ids` set as a hit `NOT_condition_id`, and record the half-hit path of the NOT-condition.
* Traverse the `NOT_condition_group` of `attribute_id`. For each `group_id`, form a key `{group_id, attribute_id, 1}` to obtain the `NOT_condition_id`. If it is in the `exclude condition_ids` set, ignore it; otherwise, add it to the `all hit condition_ids` set as a hit `NOT_condition_id`, and record the half-hit path of the negate-condition.
* Use the `all hit condition_ids` to calculate if there are any newly hit rule_ids. If there are, populate the half-hit path of the NOT-condition which will become full-hit path.
* Use the `all hit condition_ids` to calculate if there are any newly hit rule_ids. If there are, populate the half-hit path of the negate-condition which will become full-hit path.
3. **xx_get_hit_path**: This interface is used to retrieve the hit path.

View File

@@ -22,7 +22,7 @@ The statistical information in the above figure is divided into two parts, part1
- plug_acc_num: total number of configurations for plugin tables
- NOT_condition_num: total number of NOT-conditions
- NOT_condition_num: total number of negate-conditions
- excl_grp_num: total number of exclude groups

View File

@@ -60,7 +60,7 @@ The relationship between group and rule is stored in the [group2rule table](./ma
A condition consists of several Literals and the relationship between them is a `logical 'OR'`.
Conditions are divided into two categories based on whether they contain the logical "NOT" operation: `condition` and `NOT-condition`. In Maat, the logical "NOT" only appears in the condition, which means that if you want to use the logical "NOT", you need to configure conditions for the rules.
Conditions are divided into two categories based on whether they contain the logical "NOT" operation: `condition` and `negate-condition`. In Maat, the logical "NOT" only appears in the condition, which means that if you want to use the logical "NOT", you need to configure conditions for the rules.
## Literal