Capability-driven security state machine-based microkernel operating system permission management method

Abstract

The embodiment of the application provides a microkernel operating system permission management method based on a capability-driven security state machine, when the operating system microkernel receives a message of kernel object access, detecting whether a security event exists in the capability request in the access; when the microkernel currently exists a security event in a sliding window, performing weighted scoring on the security event existing therein to obtain a current system threat value; switching the current security state of the microkernel according to the system threat value; and performing capability hierarchical control on the access of the kernel object according to the switched security state. The embodiment of the application performs operating system dynamic permission management based on capability driving, proposes a complete security closed-loop architecture of "detection-evaluation-response-limitation", and solves the technical problems of inaccurate rule violation response evaluation, lack of linkage between capability and security monitoring, lack of capability feedback limitation mechanism, and coarse security management event classification granularity in the prior art.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to a method for permission control in a microkernel operating system based on a capability-driven security state machine. Background Technology

[0002] In existing security-critical systems, the permission management of microkernel operating systems mainly includes capability-based schemes, token-based degradation schemes, and independent monitoring module schemes.

[0003] Existing capability-based solutions have the following significant drawbacks: limitations of static permission checking schemes; a single response mechanism that uses the same handling method for all violations and lacks a tiered response strategy; and system isolation, with the capability system and security monitoring system operating independently and lacking a linkage mechanism, resulting in the inability to trigger system-level defense actions after a threat is detected.

[0004] The token-based degradation scheme has the following drawbacks: coarse granularity, degradation usually adopts an "all or nothing" approach, and lacks progressive control over intermediate states.

[0005] The independent monitoring module solution has the following coordination problems: delay and inconsistency. The monitoring module and the capability system interact through message passing, which results in uncertain response delays, and the states of the two may be inconsistent; incomplete feedback loop. The monitoring module has difficulty directly intervening in the authorization of the capability system and cannot form a closed loop of "detection-response". Summary of the Invention

[0006] In view of this, the embodiments of this application provide a microkernel operating system permission control method based on capability-driven security state machine. The technical solution of the embodiments of this application is based on capability-driven operating system permission control, and proposes a complete security closed-loop architecture of "detection-evaluation-response-restriction". It solves the technical problems existing in the prior art, such as inaccurate evaluation of violation response, lack of linkage between capability and security monitoring, lack of capability feedback restriction mechanism, and coarse granularity of security management event classification.

[0007] In a first aspect, embodiments of this application provide a microkernel operating system permission control method based on a capability-driven security state machine, comprising: when the operating system microkernel receives a message for accessing a kernel object, detecting whether a security event exists in the capability request of the access; when the microkernel currently contains the security event in a sliding window, performing a weighted score on the existing security event to obtain a current system threat value; switching the current security state of the microkernel according to the system threat value; and performing capability-level control on access to the kernel object according to the switched security state.

[0008] Based on the above, a complete security closed-loop architecture of "detection-evaluation-response-restriction" is proposed to achieve dynamic permission control of the operating system by performing security detection on the capability requests for access to kernel objects. This architecture solves the technical problems existing in the prior art, such as inaccurate evaluation of violation response, lack of linkage between capability and security monitoring, lack of capability feedback and restriction mechanism, and coarse granularity of security management event classification.

[0009] In one possible implementation of the first aspect, weighting the security events present in the sliding window includes: obtaining the product of the severity coefficient and the time coefficient of each security event in the sliding window; the time coefficient of each security event decreases as the problem exists for a longer period of time; and weighting the security events present in the sliding window according to the product.

[0010] As shown above, the security events within the sliding window are weighted and scored based on the product of the severity coefficient and the time coefficient of each security event. This not only scores the security events based on their severity but also achieves the effect of a sliding window, where older security events automatically reduce their impact over time, while new security events rapidly increase their threat value.

[0011] In one possible implementation of the first aspect, the time coefficient of each security event decreases negatively with the duration of the security event.

[0012] As shown above, by having the time coefficient of each security event decrease negatively with the duration of the security event, it is realized that the impact of security events will automatically decrease over time, while new security events will rapidly increase the threat value.

[0013] In one possible implementation of the first aspect, the security event is divided into four levels, and the severity coefficient changes positively with the level; the first level includes: authorization failure; the second level includes one of the following: access timeout, availability degradation; the third level includes one of the following: unauthorized access, integrity failure; the fourth level includes one of the following: insufficient permissions, kernel object tampering.

[0014] Based on the above, security incidents are divided into four severity levels, from first to fourth. The severity coefficient of each level changes positively with the level, thus achieving accurate scoring of security incidents based on their severity.

[0015] In one possible implementation of the first aspect, switching the current security state of the microkernel based on the system threat value includes: switching the current security state of the microkernel based on the system threat value and the duration of the current security state.

[0016] Based on the above, the security status of the operating system microkernel is managed according to the system threat value and duration of security events, thereby achieving fine-grained security management.

[0017] In one possible implementation of the first aspect, the security state of the microkernel includes a normal state, a degraded state, a warning state, and an emergency state. The microkernel's current security state is switched based on the system threat value and the duration of the current security state, including: when the microkernel's security state is normal and the system threat value is greater than or equal to a first threat threshold but less than a second threat threshold, the microkernel's security state is switched to a degraded state; when the microkernel's security state is degraded or normal and the system threat value is greater than or equal to the second threat threshold but less than a third threat threshold, or when the microkernel's security state is degraded and the duration is greater than or equal to a first duration, the microkernel's security state is switched to a warning state; when the microkernel's security state is warning, degraded, or normal and the system threat value is greater than or equal to a third threat threshold, or when the microkernel's security state is warning and the duration is greater than or equal to a second duration, the microkernel's security state is switched to an emergency state; wherein the first threat threshold is less than the second threat threshold, and the second threat threshold is less than the third threat threshold. The process of switching the current security state of the microkernel based on the system threat value and duration further includes: when the security state of the microkernel is in a downgraded state or a warning state, the security state of the microkernel is switched to a secure state when the system threat value is less than a fourth threat threshold and the duration exceeds a third duration, wherein the fourth threat threshold is less than a first threat threshold.

[0018] Based on the above, the security status of the operating system microkernel is divided into normal status, degraded status, warning status, and emergency status. When switching states, not only the current threat score is considered, but also the duration is checked, so as to realize hierarchical management of the security status of the operating system microkernel. It not only upgrades and switches when the threat increases, but also restores and switches when the threat is eliminated.

[0019] In one possible implementation of the first aspect, capability-based control of access to kernel objects includes: when the microkernel's security state is in a degraded state, limiting the rate at which non-critical tasks create new capabilities to access kernel objects; when the microkernel's security state is in a degraded state, prohibiting all tasks from generating new capabilities based on their current capabilities to access kernel objects; and when the microkernel's security state is in an emergency state, denying any task the capability to access kernel objects or denying any task other than a preset task the capability to access kernel objects.

[0020] Based on the above, corresponding capability control methods are adopted for each security state to achieve fine-grained security management of the operating system microkernel.

[0021] Secondly, embodiments of this application provide a microkernel operating system permission control architecture based on a capability-driven security state machine, comprising: a capability manager, used to detect whether a security event exists in the capability request of the access when the operating system microkernel receives a message for accessing a kernel object; a security event processing center, used to perform weighted scoring on the security events present in the sliding window when the microkernel currently contains the security events, to obtain the current system threat value; a security state machine, used to switch the current security state of the microkernel according to the system threat value and duration; and a capability feedback controller, used to perform capability-level control on the access to kernel objects according to the switched security state.

[0022] Based on the above, a complete security closed-loop architecture of "detection-evaluation-response-restriction" is proposed to achieve dynamic permission control of the operating system by performing security detection on the capability requests for access to kernel objects. This architecture solves the technical problems existing in the prior art, such as inaccurate evaluation of violation response, lack of linkage between capability and security monitoring, lack of capability feedback and restriction mechanism, and coarse granularity of security management event classification.

[0023] In one possible implementation of the second aspect, the security incident processing center is specifically used to obtain the product of the severity coefficient and the time coefficient of each security incident within the sliding window, wherein the time coefficient of each security incident decreases as the problem persists; and is also used to perform weighted scoring on the security incidents existing within the sliding window based on the product.

[0024] As shown above, the security events within the sliding window are weighted and scored based on the product of the severity coefficient and the time coefficient of each security event. This not only scores the security events based on their severity but also achieves the effect of a sliding window, where older security events automatically reduce their impact over time, while new security events rapidly increase their threat value.

[0025] In one possible implementation of the second aspect, the time coefficient of each security event decreases negatively with the duration of the security event.

[0026] As shown above, by having the time coefficient of each security event decrease negatively with the duration of the security event, it is realized that the impact of security events will automatically decrease over time, while new security events will rapidly increase the threat value.

[0027] In one possible implementation of the second aspect, the security event is divided into four levels, and the severity coefficient changes positively with the level; the first level includes: authorization failure; the second level includes one of the following: access timeout, availability degradation; the third level includes one of the following: unauthorized access, integrity failure; the fourth level includes one of the following: insufficient permissions, kernel object tampering.

[0028] Based on the above, security incidents are divided into four severity levels, from first to fourth. The severity coefficient of each level changes positively with the level, thus achieving accurate scoring of security incidents based on their severity.

[0029] In one possible implementation of the second aspect, when the security state machine switches the current security state of the microkernel based on the system threat value, it is used to switch the current security state of the microkernel based on the system threat value and the duration of the current security state.

[0030] Based on the above, the security status of the operating system microkernel is managed according to the system threat value and duration of security events, thereby achieving fine-grained security management.

[0031] In one possible implementation of the second aspect, the security state of the microkernel includes a normal state, a degraded state, a warning state, and an emergency state. Specifically, the security state machine is used to: switch the microkernel's security state to a degraded state when the microkernel's security state is normal and the system threat value is greater than or equal to a first threat threshold but less than a second threat threshold; switch the microkernel's security state to a warning state when the microkernel's security state is either degraded or normal and the system threat value is greater than or equal to the second threat threshold but less than a third threat threshold, or when the microkernel's security state is degraded and the duration is greater than or equal to a first duration; switch the microkernel's security state to an emergency state when the microkernel's security state is either warning, degraded, or normal and the system threat value is greater than or equal to the third threat threshold, or when the microkernel's security state is warning and the duration is greater than or equal to a second duration; wherein the first threat threshold is less than the second threat threshold, and the second threat threshold is less than the third threat threshold. The process of switching the current security state of the microkernel based on the system threat value and duration further includes: when the security state of the microkernel is in a downgraded state or a warning state, the security state of the microkernel is switched to a secure state when the system threat value is less than a fourth threat threshold and the duration exceeds a third duration, wherein the fourth threat threshold is less than a first threat threshold.

[0032] Based on the above, the security status of the operating system microkernel is divided into normal status, degraded status, warning status, and emergency status. When switching states, not only the current threat score is considered, but also the duration is checked, so as to realize hierarchical management of the security status of the operating system microkernel. It not only upgrades and switches when the threat increases, but also restores and switches when the threat is eliminated.

[0033] In one possible implementation of the second aspect, the capability feedback controller is specifically configured to: when the microkernel's security state is in a degraded state, restrict the rate at which non-critical tasks create new capabilities to access kernel objects; when the microkernel's security state is in a degraded state, prohibit all tasks from generating new capabilities based on their current capabilities to access kernel objects; and when the microkernel's security state is in an emergency state, refuse to grant any task the capability to access kernel objects or refuse to grant any task other than a preset task the capability to access kernel objects.

[0034] Based on the above, corresponding capability control methods are adopted for each security state to achieve fine-grained security management of the operating system microkernel.

[0035] Thirdly, embodiments of this application provide a computing device, including,

[0036] bus;

[0037] A communication interface, which is connected to the bus;

[0038] At least one processor connected to the bus; and

[0039] At least one memory is connected to the bus and stores program instructions that, when executed by the at least one processor, cause the at least one processor to perform the method described in any embodiment of the first aspect of this application.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium having program instructions stored thereon, which, when executed by a computer, cause the computer to perform the method described in any embodiment of the first aspect. Attached Figure Description

[0041] Figure 1 This is a flowchart illustrating an embodiment of a capability-driven security state machine-based microkernel operating system permission control method according to this application.

[0042] Figure 2 This is a flowchart illustrating a second embodiment of a microkernel operating system permission control method based on a capability-driven security state machine, as described in this application.

[0043] Figure 3This is a schematic diagram of the detection-scoring-control architecture in Embodiment 2 of the microkernel operating system permission management method based on capability-driven security state machine of this application;

[0044] Figure 4 This is a schematic diagram of a first embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine according to this application;

[0045] Figure 5 This is a schematic diagram of a second embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine, as described in this application.

[0046] Figure 6 This is a schematic diagram of the workflow between the components in a second embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine according to this application;

[0047] Figure 7 This is a schematic diagram of the computing device of this application. Detailed Implementation

[0048] To make this application easier to understand, specific embodiments are described below to further illustrate this application. The technical solutions provided by this application are further explained below with reference to the accompanying drawings and examples. It should be understood that the system architecture and business scenarios provided in the embodiments of this application are mainly for illustrating possible implementations of the technical solutions of this application and should not be construed as the sole limitation on the technical solutions of this application. Those skilled in the art will recognize that, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided by this application are equally applicable to similar technical problems.

[0049] It should be understood that the memory management solutions provided in this application include projection methods, devices, vehicles, and AR-HUDs. Since these technical solutions solve problems based on the same or similar principles, some repetitive details may not be repeated in the following descriptions of specific embodiments. However, it should be considered that these specific embodiments have mutual references and can be combined with each other.

[0050] This application provides a dynamic permission control method for a microkernel operating system based on a capability-driven security state machine. The method includes: when the operating system microkernel receives a message for accessing a kernel object, detecting whether there is a security event in the capability request of the access; when the microkernel currently has the security event in a sliding window, performing a weighted score on the existing security event to obtain the current system threat value; switching the current security state of the microkernel according to the system threat value; and performing capability-level control on the access to the kernel object according to the switched security state.

[0051] The technical solution of this application embodiment is based on capability-driven dynamic permission control of the operating system, and proposes a complete security closed-loop architecture of "detection-evaluation-response-restriction", which solves the technical problems existing in the prior art, such as inaccurate evaluation of violation response, lack of linkage between capability and security monitoring, lack of capability feedback restriction mechanism, and coarse granularity of security management event classification.

[0052] The embodiments of this application are described below with reference to the accompanying drawings. Figure 1 This paper introduces an embodiment of a microkernel operating system permission control method based on a capability-driven security state machine.

[0053] Figure 1 The flowchart of a microkernel operating system permission control method based on capability-driven security state machine is shown in Embodiment 1, including steps S110 to S140.

[0054] S110: When the operating system microkernel receives a message for accessing a kernel object, it checks whether there is a security event in the capability request of the access.

[0055] The operating system microkernel can be either a microkernel or a monolithic kernel. Kernel objects can be memory, devices, inter-process communication (IPC), etc. The operating system microkernel has a built-in capability manager that detects whether there are security events in the capability request during the access.

[0056] For example, when a request to access a kernel object is received, if a security issue is detected through a permission check hook, the request will not only be rejected, but the interface will also be called to report the violation details to the kernel's security state machine.

[0057] For example, the aforementioned security events include at least: access timeout, availability degradation, unauthorized access, integrity failure, insufficient privileges, and kernel object tampering.

[0058] S120: When a security event exists within the sliding window of the operating system microkernel, a weighted score is calculated for the security event within the sliding window to obtain the current system threat value.

[0059] In order to accurately assess the impact of security incidents, this embodiment introduces a sliding window to ignore security incidents outside the sliding window, i.e., security incidents from a long time ago, and to more accurately assess security incidents within the sliding window based on weighted coefficients.

[0060] In some embodiments, security events are categorized into four severity levels, from first to fourth. Each level sets a severity coefficient for the security event, used to accurately score the event. The severity coefficient increases positively with each level, with level 4 having the highest severity coefficient. The first level includes: authorization failure; the second level includes one of the following: access timeout, availability degradation; the third level includes one of the following: unauthorized access, integrity failure; and the fourth level includes one of the following: insufficient permissions, kernel object tampering. These four levels cover all security events.

[0061] In some embodiments, when weighting the security events within a sliding window, the product of the severity coefficient and the time coefficient of each security event in the current sliding window is obtained, with the time coefficient of each security event decreasing as the problem persists. The security events within the sliding window are then weighted and scored based on this product. This scoring method ensures that older security events automatically decrease in impact over time, while new security events rapidly increase the threat value.

[0062] S130: Switch the current security state of the operating system microkernel based on the current system threat value.

[0063] The higher the system threat value, the higher the security risk, and the higher the level of capability control over access to operating system microkernel objects. This achieves a closed loop of security event assessment and capability control, and enables fine-grained control over capabilities.

[0064] In some embodiments, the current security state of the operating system microkernel is switched based on the current system threat value and duration. Managing the security state of the operating system microkernel based on the system threat value and duration of security events enables fine-grained security management.

[0065] In some embodiments, the security state of the operating system microkernel includes a normal state, a degraded state, a warning state, and an emergency state, thereby enabling hierarchical management of the security state of the operating system microkernel.

[0066] In some embodiments, when the operating system microkernel's security state is normal and the current system threat value is greater than or equal to a first threat threshold but less than a second threat threshold, the threat has increased, and the operating system microkernel's security state switches to a degraded state. When the operating system microkernel's security state is degraded or normal and the system threat value is greater than or equal to a second threat threshold but less than a third threat threshold, or when the operating system microkernel's security state is degraded and the duration is greater than or equal to a first duration, the threat continues to increase, and the operating system microkernel's security state switches to a warning state. When the operating system microkernel's security state is warning, degraded, or normal and the current system threat value is greater than or equal to a third threat threshold, or when the operating system microkernel's security state is warning and the duration is greater than or equal to a second duration, the threat is very serious, and the operating system microkernel's security state switches to an emergency state.

[0067] In some embodiments, when the security state of the operating system microkernel is in a degraded state or a warning state, the security state of the operating system microkernel switches to a normal state when the current system threat value is less than the fourth threat threshold and the duration exceeds the third duration. That is, the system threat is eliminated, the operating system recovers, and capability distribution is also restored accordingly. The fourth threat threshold is less than the first threat threshold.

[0068] S140: Based on the security state after the switch, perform capability-level control on access to kernel objects.

[0069] In some embodiments, when the security state of the operating system microkernel is in a degraded state, the rate at which non-critical tasks create new capabilities to access kernel objects is limited; when the security state of the operating system microkernel is in a degraded state, all tasks are prohibited from generating new capabilities based on their current capabilities to access kernel objects; when the security state of the operating system microkernel is in an emergency state, any task is denied the ability to access kernel objects or any task other than a preset task is denied the ability to access kernel objects, thereby achieving fine-grained control of capabilities based on security events.

[0070] In summary, the first embodiment of a capability-driven security state machine-based microkernel operating system permission control method proposes a complete security closed-loop architecture of "detection-evaluation-response-restriction" to address the technical problems existing in the prior art, such as inaccurate violation response evaluation, lack of linkage between capability and security monitoring, lack of capability feedback restriction mechanism, and coarse-grained security management event classification.

[0071] The following is combined with Figures 2 to 3 This paper introduces a second embodiment of a microkernel operating system permission control method based on a capability-driven security state machine.

[0072] Embodiment 2 of a microkernel operating system permission control method based on capability-driven security state machine is a detailed implementation of Embodiment 1 of the same method, and possesses all its advantages.

[0073] In this embodiment, the following data structure is defined.

[0074] (1) Security event enumeration types:

[0075] typedef enum

[0076] {

[0077] SECURITY_EVENT_CAPABILITY_VIOLATION, / *Unauthorized access* /

[0078] SECURITY_EVENT_AUTHORIZATION_FAILURE, / * Authorization failed * /

[0079] SECURITY_EVENT_DENIAL_OF_CAPABILITY, / * Capability denial * /

[0080] SECURITY_EVENT_TIMEOUT_EXCEEDED, / *Access timeout* /

[0081] SECURITY_EVENT_INTEGRITY_FAILURE, / * Integrity failure* /

[0082] SECURITY_EVENT_AVAILABILITY_DEGRADATION, / *Availability degradation* /

[0083] SECURITY_EVENT_ANOMALY_DETECTED, / * Kernel object tampering * /

[0084] SECURITY_EVENT_COUNT / * Total number of events /

[0085] } security_event_type_t.

[0086] (2) Security state enumeration type:

[0087] typedef enum

[0088] {

[0089] SECURITY_STATE_NORMAL, / * Normal state: All capabilities are functioning normally * /

[0090] SECURITY_STATE_DEGRADED, / * Degraded status: Restricts ability distribution * /

[0091] SECURITY_STATE_ALERT, / * Alarm status: Freeze non-critical capabilities * /

[0092] SECURITY_STATE_PANIC, / * Emergency state: Freeze all capabilities * /

[0093] SECURITY_STATE_COUNT / * Total number of states, used for array indexing * /

[0094] } security_state_t.

[0095] (3) Security event structure:

[0096] typedef struct {

[0097] security_event_type_t type; / * Event type * /

[0098] uint32_t source_task_id; / * Source task ID * /

[0099] uint32_t target_object_id; / * Target object ID * /

[0100] uint32_t capability_handle; / * Handle to the relevant capability * /

[0101] uint64_t timestamp_ms; / * Event timestamp * /

[0102] uint32_t event_data[4]; / * Additional event data * /

[0103] uint32_t severity; / * Severity level [0-3] * /

[0104] } security_event_t.

[0105] (4) Severity level of security incident (different from security status enumeration type):

[0106] typedef enum {

[0107] SEVERITY_LOW = 0, / *Low severity: Log messages * /

[0108] SEVERITY_MEDIUM, / *Medium severity: Increase the count* /

[0109] SEVERITY_HIGH, / * High severity: triggers state transition * /

[0110] SEVERITY_CRITICAL / * Extremely high severity: Immediate state transition * /

[0111] } security_severity_t.

[0112] (5) Safety state machine control block (containing complete runtime context information of the state machine):

[0113] typedef struct {

[0114] security_state_t current_state; / * Current security state * /

[0115] security_state_t previous_state; / * Previous security state * /

[0116] / *The following is an event statistics report* /

[0117] uint32_t event_counts[SECURITY_EVENT_COUNT]; / * Counts events of various types * /

[0118] uint32_t violation_total_count; / * Total number of violations * /

[0119] uint32_t violation_recent_count; / * Recent violation count (scrolling window) * /

[0120] / *The following is a state transition lock record* /

[0121] uint64_t last_transition_timestamp; / * Timestamp of the last state transition * /

[0122] uint32_t transition_count; / *Count the number of state transitions* /

[0123] uint8_t transition_locked : 1; / * State transition locking flag * /

[0124] / *The following are the durations of each state* /

[0125] uint64_t state_entry_timestamp; / * The time when the current state was entered * /

[0126] uint64_t total_normal_duration_ms; / * Total normal duration * /

[0127] uint64_t total_degraded_duration_ms; / * Cumulative degraded duration * /

[0128] / * The following is the capability feedback configuration * /

[0129] struct {

[0130] uint8_t limit_new_caps : 1; / * Limit the issuance of new capabilities * /

[0131] uint8_t freeze_derivation : 1; / * Freeze the ability* /

[0132] uint8_t revoke_non_critical : 1; / * Revoke a non-critical capability * /

[0133] uint8_t freeze_all_caps : 1; / * Freeze all caps * /

[0134] } capability_feedback;

[0135] / * Recovery condition determination * /

[0136] uint64_t recovery_start_timestamp; / * Recovery timer start timestamp * /

[0137] uint32_t recovery_threshold_ms; / * Recovery threshold time * /

[0138] / * Callback function * /

[0139] void (*state_change_callback)(security_state_t old, security_state_tnew);

[0140] void (*feedback_callback)(const security_state_t *state);

[0141] } security_fsm_context_t.

[0142] (6) Capability feedback control structure:

[0143] typedef struct {

[0144] / * Ability distribution restrictions * /

[0145] uint32_t max_new_caps_per_tick; / * Maximum number of new caps issued per scheduling cycle * /

[0146] uint32_t cap_creation_delay_ms; / * Capability creation delay time * /

[0147] uint8_t allow_derived_caps; / * Whether to allow the derived capabilities * /

[0148] uint8_t allow_cap_transfer; / * Whether capability transfer is allowed * /

[0149] / * Existing capacity constraints * /

[0150] uint8_t freeze_non_critical_caps; / * Freeze non-critical capabilities * /

[0151] uint8_t freeze_all_caps; / * Freeze all caps* /

[0152] uint32_t revocation_timeout_ms; / * Timeout for revocation * /

[0153] / * Object-specific constraints * /

[0154] uint32_t restricted_object_mask; / * Restricted object mask * /

[0155] uint32_t trusted_task_mask; / * Trusted task mask (unrestricted) * /

[0156] } capability_feedback_config_t.

[0157] Figure 2 The flowchart of a second embodiment of a microkernel operating system permission control method based on capability-driven security state machine is shown, including steps S210 to S250.

[0158] S210: Security Event Detection. When the operating system microkernel receives a message accessing a kernel object, it checks whether a security event exists in the capability request of that access.

[0159] If a security event occurs, proceed to step S220; otherwise, return to this step.

[0160] S220: Security Incident Pre-processing. Detected security incidents are classified into four levels, and a severity coefficient is obtained for each level.

[0161] The first level is the low level, which includes: authorization failure; the second level is the medium level, which includes one of the following: access timeout, availability degradation; the third level is the high level, which includes one of the following: unauthorized access, integrity failure; and the fourth level is the critical level, which includes one of the following: insufficient permissions, kernel object tampering.

[0162] S230: Security Incident Scoring. When a security incident exists within the sliding window, a weighted score is calculated based on the security system and duration of each security incident to obtain the current system threat value.

[0163] The current system threat value is obtained using equation (1).

[0164] (1)

[0165] In the formula, t is the current time. The current system threat level. This represents the total number of security events currently within the sliding window. For security incident sequence numbers, For security incidents Time, For security incidents The severity level corresponds to the security level. For security incidents time coefficient, It is the attenuation coefficient (in this embodiment) =0.1), used to achieve the sliding window effect. Defined by equation (2).

[0166] (2)

[0167] S240: Security state transition. The security state of the current operating system microkernel is transitioned based on the current system threat level and duration.

[0168] The current security state of the operating system microkernel is divided into four levels: NORMAL, DEGRADED, ALERT (warning), and PANIC (emergency). Table 1 shows the security state switching table of the operating system microkernel.

[0169] Table 1

[0170] NORMAL DEGRADED Instantaneous trigger NORMALDEGRADED ALERT T(t)≥150 or lasts for 30s in the Degraded state NORMALDEGRADEDALERT PANIC T(t)≥500 or lasts for 10s in ALERT state. DEGRADEDALERT NORMAL T(t) < 10 and no new violations occur for 5 seconds.

[0171] If the security state of the operating system microkernel is switched, step S250 is executed; if the security state of the operating system microkernel is not switched, step S210 is returned.

[0172] S250: Capability-based hierarchical control. Based on the security state of the operating system microkernel after the switch, capability-based hierarchical control is implemented for access to kernel objects.

[0173] Table 2 is a hierarchical control table for the ability to access operating system microkernel objects.

[0174] Table 2

[0175] NORMAL Kernel object access capabilities are being issued normally. DEGRADED Limit the rate at which non-critical tasks create new capabilities to access kernel objects. ALERT All tasks are prohibited from generating new capabilities based on their current ability to access kernel objects. PANIC Deny any task the ability to access kernel objects, or deny any task other than the default task the ability to access kernel objects.

[0176] Below is an example of a capability feedback configuration table.

[0177] capability_feedback_config_t {

[0178] / * Capability control configuration under normal conditions * /

[0179] [SECURITY_STATE_NORMAL] = {

[0180] `.max_new_caps_per_tick = 256`, / * The maximum number of new caps that can be generated is 256, with no limit * /

[0181] .cap_creation_delay_ms = 0, / * No delay in creating new capabilities, no limit * /

[0182] .allow_derived_caps = 1, / * Allows derived capabilities without restriction * /

[0183] .allow_cap_transfer = 1, / * Allow capability transfer without restrictions * /

[0184] .freeze_non_critical_caps = 0, / * Do not freeze non-critical capabilities, no restrictions * /

[0185] .freeze_all_caps = 0, / * Do not freeze all abilities, no restrictions * /

[0186] .revocation_timeout_ms = 0, / *Unlimited timeout for ability revocation* /

[0187] .restricted_object_mask = 0, / *No kernel objects are restricted* /

[0188] `.trusted_task_mask = 0xFFFFFFFF` / * Trust all tasks * /

[0189] },

[0190] / * Capability control configuration in downgraded state * /

[0191] [SECURITY_STATE_DEGRADED] = {

[0192] `.max_new_caps_per_tick = 32` / * The maximum number of new caps that can be generated is 32, which is a limitation. * /

[0193] .cap_creation_delay_ms = 10, / * There is a 10ms delay before creating a new capability, which is limited * /

[0194] .allow_derived_caps = 1, / * Allows derived capabilities without restriction * /

[0195] .allow_cap_transfer = 0, / * Capability transfer is not allowed, restriction * /

[0196] .freeze_non_critical_caps = 0, / * Do not freeze non-critical capabilities, no restrictions * /

[0197] .freeze_all_caps = 0, / * Do not freeze all abilities, no restrictions * /

[0198] .revocation_timeout_ms = 5000, / * There is a time limit for revocation* /

[0199] .restricted_object_mask = 0x00000001, / * Kernel object 0 is restricted * /

[0200] .trusted_task_mask = 0x00000001 / * Trusted task ID=0 * /

[0201] },

[0202] / * Capability control configuration in warning state * /

[0203] [SECURITY_STATE_ALERT] = {

[0204] `.max_new_caps_per_tick = 4` / * The maximum number of new caps that can be generated is 4, which is a limitation. * /

[0205] .cap_creation_delay_ms = 100, / * There is a 100ms delay before creating a new capability, which is limited * /

[0206] .allow_derived_caps = 0, / * Derived capabilities are not allowed; there are restrictions* /

[0207] .allow_cap_transfer = 0, / * Ability transfer is not allowed and is restricted * /

[0208] .freeze_non_critical_caps = 1, / * Freeze non-critical capabilities, with limitations * /

[0209] .freeze_all_caps = 0, / * Do not freeze all abilities, no restrictions * /

[0210] .revocation_timeout_ms = 1000, / * There is a time limit for revocation. * /

[0211] .restricted_object_mask = 0xFFFFFFFE, / * Kernel objects other than 0 are restricted * /

[0212] .trusted_task_mask = 0x00000001 / * Trusted task ID=0 * /

[0213] },

[0214] [SECURITY_STATE_PANIC] = {

[0215] `.max_new_caps_per_tick = 0` / * New caps cannot be generated; there are limitations. * /

[0216] .cap_creation_delay_ms = 0, / * Invalid * /

[0217] .allow_derived_caps = 0, / * Derived capabilities are not allowed; there are restrictions* /

[0218] .allow_cap_transfer = 0, / * Ability transfer is not allowed and is restricted * /

[0219] .freeze_non_critical_caps = 1, / * Freeze non-critical capabilities, with limitations * /

[0220] .freeze_all_caps = 1, / * Freeze all caps, with limitations * /

[0221] .revocation_timeout_ms = 100, / * There is a time limit for revocation. * /

[0222] .restricted_object_mask = 0xFFFFFFFF, / * Kernel objects are restricted * /

[0223] .trusted_task_mask = 0x00000000 / * Untrusted tasks * /

[0224] }

[0225] }

[0226] The following is combined with Figure 3 This paper introduces a microkernel operating system permission management method based on capability-driven security state machine, specifically the detection-scoring-control architecture in Example 2.

[0227] (1) First is the detection of security events in the requirements for accessing kernel objects. Security events are divided into 7 categories;

[0228] (2) Then, the 7 types of security events are scored based on a sliding window, and the status is switched based on the scoring results, which are divided into 4 security states;

[0229] (3) Finally, the access capabilities of kernel objects are controlled hierarchically according to the switched security state.

[0230] In summary, Embodiment 2 of a microkernel operating system permission control method based on a capability-driven security state machine implements a dynamic permission control method for the operating system based on a capability-driven security state machine. This addresses technical problems in existing technologies, such as coarse-grained violation response, lack of linkage between the capability system and security monitoring, lack of capability feedback restriction mechanisms, unreasonable state transition conditions, and imperfect security event classification. Specifically, this embodiment achieves the following technical objectives: Establishing a rapid response channel: Establishing a direct channel from capability violation to security state transition, eliminating delays in intermediate links; Achieving fine classification: Designing a seven-category security event classification system, providing precise descriptions and differentiated strategies for different types of violation security implementations; Constructing bidirectional feedback: Implementing a bidirectional feedback mechanism between the capability system and the security state machine, enabling the state machine to restrict the granting of permissions to the capability system; Progressive degradation: Constructing a four-level progressive security response strategy from NORMAL to DEGRADED to ALERT to PANIC; Optimizing recovery logic: Establishing a recovery judgment mechanism based on duration and violation clearing, avoiding frequent state jumps and oscillations at critical points.

[0231] The following is combined with Figure 4 This paper introduces an example of a microkernel operating system permission management architecture based on a capability-driven security state machine.

[0232] An embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine is described in Embodiment 1. The method described in Embodiment 1, which is based on a capability-driven security state machine, has all its advantages.

[0233] Figure 4 The structure of a microkernel operating system permission control architecture based on a capability-driven security state machine is shown in Embodiment 1, including: a capability manager 410, a security event center 420, a security state machine 430, and a capability feedback controller 440.

[0234] Capability manager 410 is used to detect whether a security event exists in the capability request of an access request when the operating system microkernel receives a message for accessing a kernel object. For its working principle and advantages, please refer to step S110 of Embodiment 1 of a microkernel operating system permission control method based on a capability-driven security state machine.

[0235] The security event center 420 is used to perform weighted scoring on the security events existing in the sliding window of the operating system microkernel when such events are currently present, thereby obtaining the current system threat value. For its working principle and advantages, please refer to step S120 of Embodiment 1 of a Microkernel Operating System Permission Control Method Based on Capability-Driven Security State Machine.

[0236] The security state machine 430 switches the current security state of the operating system microkernel based on the current system threat value. For its working principle and advantages, please refer to step S130 of Embodiment 1 of a Microkernel Operating System Permission Control Method Based on a Capability-Driven Security State Machine.

[0237] The capability feedback controller 440 is used to perform capability-level control on access to kernel objects based on the switched security state. For its working principle and advantages, please refer to step S140 of Embodiment 1 of a microkernel operating system permission management method based on a capability-driven security state machine.

[0238] The following is combined with Figures 5 to 6 This paper introduces a second embodiment of a microkernel operating system permission management architecture based on a capability-driven security state machine.

[0239] Example 2 of a microkernel operating system permission control architecture based on capability-driven security state machine: The method described in Example 2 of a microkernel operating system permission control method based on capability-driven security state machine has all its advantages.

[0240] Figure 5 The diagram illustrates the structure of a second embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine, including: microkernel components and a multi-level security state machine.

[0241] The microkernel components include task management, memory management, device management, communication management, and capability manager 510. The home security state machine includes: capability manager 510, security event processing center 520, security state machine 530, and capability feedback controller 540. Task management, memory management, device management, and communication management are standard components and will not be described in detail here.

[0242] Capability Manager 510 performs security event detection on kernel object access capabilities in task management, memory management, device management, and communication management. When the operating system microkernel receives a message for accessing a kernel object, it checks whether a security event exists in the capability request. For its working principle and advantages, please refer to step S210 of Embodiment 2 of a Microkernel Operating System Permission Control Method Based on Capability-Driven Security State Machine.

[0243] The security incident processing center 520 is used to classify detected security incidents into four levels and obtain the severity coefficient for each level. It is also used to, when a security incident exists within a sliding window, to perform a weighted score on the security incidents in the sliding window based on the security system and duration of each incident, thereby obtaining the current system threat value. For its working principle and advantages, please refer to steps S220 and S230 of Embodiment 2 of a microkernel operating system permission control method based on a capability-driven security state machine.

[0244] The security state machine 530 is used to switch the security state of the current operating system microkernel based on the current system threat value and duration. For its working principle and advantages, please refer to step S240 of Embodiment 2 of a microkernel operating system permission control method based on a capability-driven security state machine.

[0245] The capability feedback controller 540 is used to determine the capability-level control of access to kernel objects based on the security state of the switched operating system microkernel, and then feeds this control back to the capability manager. For its working principle and advantages, please refer to step S250 of Embodiment 2 of a capability-driven security state machine-based microkernel operating system permission control method.

[0246] Figure 6 This diagram illustrates the workflow between components in a second embodiment of a microkernel operating system permission control architecture based on a capability-driven security state machine. For simplicity, the components are not numbered; note that the core state machine in the diagram is a security state machine. The workflow includes:

[0247] (1) When a task attempts to access a protected kernel object, the capability manager performs a permission check. If the check passes, the process ends. If the check fails, the capability manager calls report_event() to report the event to the security event handling center.

[0248] (2) The security incident handling center classifies security incidents according to preset rules by evaluating_severity() and obtains the weight value W of the security incident by querying the severity weight table.

[0249] (3) The security incident processing center receives the weight value W and performs a security score using update_threat_socre() to update the current threat value T. This invention uses an exponential decay algorithm to calculate T, meaning that each new violation increases T, but the impact of older violations automatically decays over time. This reflects the current real-time threat better than a simple counter.

[0250] (3) The state machine core calls check_transition_condition() to perform a safety state transition assessment.

[0251] In the Normal state, the state machine enters the Degraded state only when T exceeds the degradation threshold (50). In the Degraded state, the system not only monitors T but also starts a "degradation duration timer." If T drops below the recovery threshold (10) and remains below it for 5 seconds, the system reverts to Normal. If T continues to rise above 150, or the degraded state persists for more than 30 seconds (to prevent attackers from maintaining the degraded state for an extended period through low-frequency attacks), the system enters Alert. In the Degraded or Alert state, if the threat value TT decreases due to the cessation of the attack, the state machine does not immediately revert but instead starts a "recovery confirmation timer" (e.g., 5 seconds). Reverting is only performed if TT remains below the threshold during the timer's timeout period. This effectively prevents the system from repeatedly oscillating at the critical point (Chattering).

[0252] (4) The state machine core calls execute_transition() to perform a safety state transition based on the safety state transition assessment result.

[0253] (5) When a safety state transition occurs, the capability feedback controller performs hierarchical capability control based on the state after the transition using apply_feedback_policy.

[0254] When a state transition occurs, the capability feedback controller takes effect immediately. For example, when transitioning to the Degraded state, the feedback control unit issues a policy to the capability manager to limit the rate at which non-critical tasks create new capabilities (e.g., a maximum of 10 per second) and logs the changes. When transitioning to the Alert state, all capability derivations are frozen, meaning tasks are prohibited from generating new capabilities based on existing capabilities, thus cutting off the attack propagation path. When transitioning to the Panic state, all capability entries are immediately frozen, any new permission grants are denied, and only preset "security tasks" (such as logging tasks) are allowed to run.

[0255] This application also provides a computing device, which will be described below in conjunction with... Figure 7 Detailed introduction.

[0256] The computing device 700 includes a processor 710, a memory 720, a communication interface 730, and a bus 740.

[0257] It should be understood that the communication interface 730 in the computing device 700 shown in the figure can be used to communicate with other devices.

[0258] The processor 710 can be connected to the memory 720. The memory 720 can be used to store the program code and data. Therefore, the memory 720 can be a storage unit inside the processor 710, an external storage unit independent of the processor 710, or a component that includes both the storage unit inside the processor 710 and the external storage unit independent of the processor 710.

[0259] Optionally, the computing device 700 may also include a bus 740. The memory 720 and communication interface 730 can be connected to the processor 710 via the bus 740. The bus 740 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The bus 740 can be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one line is used in this figure, but this does not mean that there is only one bus or one type of bus.

[0260] It should be understood that in the embodiments of this application, the processor 710 may be a central processing unit (CPU). The processor may also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor. Alternatively, the processor 710 may employ one or more integrated circuits to execute relevant programs to implement the technical solutions provided in the embodiments of this application.

[0261] The memory 720 may include read-only memory and random access memory, and provides instructions and data to the processor 710. A portion of the processor 710 may also include non-volatile random access memory. For example, the processor 710 may also store device type information.

[0262] When the computing device 700 is running, the processor 710 executes computer execution instructions stored in the memory 720 to perform the operation steps of each method embodiment.

[0263] It should be understood that the computing device 700 according to the embodiments of this application can correspond to the corresponding subject in executing the methods according to the various embodiments of this application, and the above and other operations and / or functions of each module in the computing device 700 are respectively for implementing the corresponding processes of the methods of this embodiment. For the sake of brevity, they will not be described in detail here.

[0264] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0265] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0266] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0267] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0268] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0269] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0270] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, is used to perform the operation steps of the various method embodiments.

[0271] The computer storage medium in this application embodiment can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. For example, a computer-readable storage medium can be, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0272] Computer-readable signal media may include data signals transmitted in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which can send, transmit, or transmit programs for use by or in connection with an instruction execution system, apparatus, or device.

[0273] The program code contained on a computer-readable medium may be transmitted using any suitable medium, including, but not limited to, wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0274] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0275] Furthermore, the terms "first, second, third, etc." or similar terms such as module A, module B, and module C used in the specification and claims are only used to distinguish similar objects and do not represent a specific ordering of objects. It is understood that, where permissible, a specific order or sequence may be interchanged so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0276] In the above description, the labels of the steps involved, such as S110, S120, etc., do not mean that the steps will necessarily be executed. The order of the steps can be interchanged or executed simultaneously if permitted.

[0277] The term "comprising" as used in the specification and claims should not be construed as limiting itself to what follows; it does not exclude other elements or steps. Therefore, it should be interpreted as specifying the presence of the mentioned feature, integral, step, or component, but does not exclude the presence or addition of one or more other features, integrals, steps, or components, or groups thereof. Thus, the statement "device comprising means A and B" should not be limited to a device consisting solely of components A and B.

[0278] The terms "an embodiment" or "an embodiment" as used in this specification mean that a particular feature, structure, or characteristic described in conjunction with that embodiment is included in at least one embodiment of this application. Therefore, the terms "in one embodiment" or "in an embodiment" appearing throughout this specification do not necessarily refer to the same embodiment, but may refer to the same embodiment. Furthermore, in one or more embodiments, the particular features, structures, or characteristics can be combined in any suitable manner, as will be apparent to those skilled in the art from this disclosure.

[0279] Note that the above are merely preferred embodiments and the technical principles employed in this application. Those skilled in the art will understand that this application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of this application, all of which fall within the scope of protection of this application.

Claims

1. A microkernel operating system permission control method based on capability-driven security state machine, characterized in that, include: When the operating system microkernel receives a message accessing a kernel object, it checks whether there is a security event in the capability request during the access. When the microkernel currently contains the security events within the sliding window, it performs a weighted score on the existing security events to obtain the current system threat value. Based on the system threat value, the current security state of the microkernel is switched; Based on the switched security state, access to kernel objects is controlled by capability hierarchy.

2. The method according to claim 1, characterized in that, The security events present within the sliding window are weighted and scored, including: Obtain the product of the severity coefficient and the time coefficient for each security event within the sliding window; the time coefficient for each security event decreases as the problem persists. The security events present in the sliding window are weighted and scored based on the product.

3. The method according to claim 2, characterized in that, The time coefficient of each security event decreases exponentially with the duration of the security event.

4. The method according to claim 2, characterized in that, The security incidents are divided into four levels, and the severity coefficient changes positively with each level. The first level includes: authorization failure; the second level includes one of the following: access timeout, availability degradation; the third level includes one of the following: unauthorized access, integrity failure; the fourth level includes one of the following: insufficient permissions, kernel object tampering.

5. The method according to claim 1, characterized in that, Based on the system threat value, the current security state of the microkernel is switched, including: The current security state of the microkernel is switched based on the system threat value and the duration of the current security state.

6. The method according to claim 5, characterized in that, The microkernel's security states include normal, degraded, warning, and emergency states. Based on the system threat value and the duration of the current security state, the microkernel's current security state is switched, including: When the microkernel's security status is normal and the system threat value is greater than or equal to the first threat threshold and less than the second threat threshold, the microkernel's security status switches to a downgraded state. When the security status of the microkernel is in a degraded state or a normal state and the system threat value is greater than or equal to the second threat threshold and less than the third threat threshold, or when the security status of the microkernel is in a degraded state and the duration is greater than or equal to the first duration, the security status of the microkernel is switched to a warning state. When the security status of the microkernel is in a warning state, a downgraded state, or a normal state and the system threat value is greater than or equal to the third threat threshold, or when the security status of the microkernel is in a warning state and the duration is greater than or equal to the second duration, the security status of the microkernel is switched to an emergency state. Among them, the first threat threshold is less than the second threat threshold, and the second threat threshold is less than the third threat threshold.

7. The method according to claim 6, characterized in that, The process of switching the current security state of the microkernel based on the system threat value and the duration of the current security state also includes: When the microkernel's security status is in a downgraded or warning state, and the system threat value is less than the fourth threat threshold for a duration exceeding the third duration, the microkernel's security status switches to a secure state, wherein the fourth threat threshold is less than the first threat threshold.

8. The method according to claim 6, characterized in that, Capability-based control of access to kernel objects includes: When the microkernel's security state is in a degraded state, the rate at which non-critical tasks create new capabilities to access kernel objects is limited. When the microkernel is in a degraded security state, all tasks are prohibited from generating new capabilities based on their current access to kernel objects. When the microkernel's security state is in an emergency state, it denies any task the ability to access kernel objects or denies any task other than the preset task the ability to access kernel objects.

9. A microkernel operating system permission control architecture based on capability-driven security state machine, characterized in that, include: The capability manager is used to detect whether a security event exists in the capability request during the access when the operating system microkernel receives a message for accessing a kernel object. The security incident processing center is used to perform a weighted score on the security incidents present in the sliding window when the microkernel currently contains the security incidents, and to obtain the current system threat value. A security state machine is used to switch the current security state of the microkernel based on the system threat value and duration. A capability feedback controller is used to perform capability-level control on access to kernel objects based on the switched security state.

10. The architecture according to claim 9, characterized in that, The security incident processing center is specifically used to obtain the product of the severity coefficient and the time coefficient of each security incident within the sliding window, and to perform a weighted score on the security incidents existing within the sliding window based on the product; the time coefficient of each security incident decreases as the problem exists for a longer period of time.

11. A computing device, characterized in that, include, bus; A communication interface, which is connected to the bus; At least one processor is connected to the bus; as well as At least one memory connected to the bus and storing program instructions that, when executed by the at least one processor, cause the at least one processor to perform the method of any one of claims 1 to 8.

12. A computer-readable storage medium, characterized in that, It stores program instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 8.

Images