@@ -31,7 +31,7 @@ A complete use case consists of three parts:
### Case1
In the scanning scenario, it is necessary to configure the schema of multiple tables, including the item table, object2rule table, and rule table. If there is also object nesting involved, the schema of the object2object table needs to be configured.
In the scanning scenario, it is necessary to configure the schema of multiple tables, including the item table, object2rule table, and rule table. If there is also object nesting involved, the schema of the object_group table needs to be configured.
**(1) table schema**
@@ -67,8 +67,8 @@ Table schema is stored in a json file(such as table_info.json), which is loaded
},
{
"table_id":2,
"table_name":"OBJECT2OBJECT",
"table_type":"object2object",
"table_name":"OBJECT_GROUP",
"table_type":"object_group",
"valid_column":4,
"custom":{
"object_id":1,
@@ -100,7 +100,7 @@ Configurations are stored in a json file(such as maat_json.json), which is loade
{
"rule_table":"RULE",
"object2rule_table":"OBJECT2RULE",
"object2object_table":"OBJECT2OBJECT",
"object_group_table":"OBJECT_GROUP",
"rules":[
{
"rule_id":123,
@@ -217,7 +217,7 @@ In the callback scenario, only the schema of the corresponding table needs to be
@@ -402,7 +402,7 @@ Configuration tags are tags stored on compilation configurations or object confi
Maat loads the configuration of different types of tables into memory to form the corresponding runtime for each table. We can see all table types from the table schema, and the runtime for the item table is similar, as it is an abstraction of the scanning engine. When we provide the data to be scanned and call the corresponding scanning interface, we can return whether the item is hit or not, and if it is hit, we can return the corresponding item’s object_id.
From the [configuration relationship](./overview.md#12-configuration-relationship) diagram, we can see how the hit object is referenced by other objects or rules. If a hit object is referenced by other objects or rules, there will be one or more hit paths that follow the `item_id -> object_id` {-> super object_id} `-> rule_id`. This requires two special runtimes: object2object_runtime and rule_runtime.
From the [configuration relationship](./overview.md#12-configuration-relationship) diagram, we can see how the hit object is referenced by other objects or rules. If a hit object is referenced by other objects or rules, there will be one or more hit paths that follow the `item_id -> object_id` {-> super object_id} `-> rule_id`. This requires two special runtimes: object_group_runtime and rule_runtime.
Based on this, we can divide the runtime into the following three categories:
@@ -413,7 +413,7 @@ Based on this, we can divide the runtime into the following three categories:
* interval_runtime
2. object & rule table runtime
* object2object_runtime
* object_group_runtime
* rule_runtime
3. xx_plugin table runtime
@@ -433,9 +433,9 @@ Among the four types of runtimes mentioned above, `expr_runtime` is relatively u
### 2.2 object & rule table runtime
#### 2.2.1 object2object runtime
#### 2.2.1 object_group runtime
The `object2object_runtime` is a runtime that is built based on the reference relationships between objects, which are stored in the [object2object table](#14-object2object-table). From the [object hierarchy](./object_hierarchy.md), we can understand that if a hit occurs in a leaf object that is referenced by other objects, there may be certain super objects that are also hit. This is exactly the functionality provided by this runtime.
The `object_group_runtime` is a runtime that is built based on the reference relationships between objects, which are stored in the [object_group table](#14-object_group-table). From the [object hierarchy](./object_hierarchy.md), we can understand that if a hit occurs in a leaf object that is referenced by other objects, there may be certain super objects that are also hit. This is exactly the functionality provided by this runtime.
@@ -20,7 +20,7 @@ As mentioned in the readme, maat has two typical usage patterns:
Different types of configurations are stored in different tables. For all configuration types, please refer to the [table schema](./maat_table.md#1-table-schema).
The physical tables are mainly divided into three categories: the item table, object rule relationship table (rule table, object2rule table, object2object table), and xx_plugin table. The first two types of tables are used for maat traffic scanning, while the xx_plugin table is used as a callback table, which can obtain the detailed configuration information for a specific key.
The physical tables are mainly divided into three categories: the item table, object rule relationship table (rule table, object2rule table, object_group table), and xx_plugin table. The first two types of tables are used for maat traffic scanning, while the xx_plugin table is used as a callback table, which can obtain the detailed configuration information for a specific key.
### 1.2 Configuration relationship
@@ -56,7 +56,7 @@ The diagram illustrates the overall architecture of maat, including the control
* **Data Plane**
When calling the maat scanning interface, it subsequently calls the table runtime of the corresponding table, then proceeds to the scanning engine. Upon the scanning engine returning a hit object, it further searches for the matching `rule_id` through object2object runtime, object2rule runtime, and rule runtime, which is then returned to the caller. In addition, if the caller is interested in the hit path, they can also retrieve it through the interfaces provided by maat.
When calling the maat scanning interface, it subsequently calls the table runtime of the corresponding table, then proceeds to the scanning engine. Upon the scanning engine returning a hit object, it further searches for the matching `rule_id` through object_group runtime, object2rule runtime, and rule runtime, which is then returned to the caller. In addition, if the caller is interested in the hit path, they can also retrieve it through the interfaces provided by maat.
The scanning mentioned above all uses the `effective runtime`. If there are configuration changes, it will trigger the construction of `updating runtime`. Once this construction is completed, it will become effective runtime, and the original effective runtime will be put into the garbage collection queue waiting to be recycled.
@@ -44,7 +44,7 @@ A object defines a set that can contain different types of items and can also re
- A Object can be referenced by different rules.
The relationship between object and object is stored in the [object2object table](./maat_table.md#14-object2object-table).
The relationship between object and object is stored in the [object_group table](./maat_table.md#14-object_group-table).
## Rule(Policy)
@@ -68,7 +68,7 @@ A Literal consists of `attribute_id(attribute id)` and `object_id`. During the r
## Physical table
Different rules are stored in different tables in the actual database, including [item table](./maat_table.md#11-item-table), [rule table](./maat_table.md#12-rule-table), [object2rule table](./maat_table.md#13-object2rule-table), [object2object table](./maat_table.md#14-object2object-table), and [xx_plugin table](./maat_table.md#15-plugin-table), and so on.
Different rules are stored in different tables in the actual database, including [item table](./maat_table.md#11-item-table), [rule table](./maat_table.md#12-rule-table), [object2rule table](./maat_table.md#13-object2rule-table), [object_group table](./maat_table.md#14-object_group-table), and [xx_plugin table](./maat_table.md#15-plugin-table), and so on.
## Attribute
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
root