Configuration method, device, equipment, medium and product of security configuration item of service

Abstract

The present disclosure relates to a method, device, equipment, medium and product for configuring security configuration items of a service. The method comprises: extracting a configuration state of at least one security configuration item of a target service; for each security configuration item with the configuration state being allowed, determining labeling information of the security configuration item based on occurrence of a behavior feature corresponding to the security configuration item in a process of the target service, wherein the labeling information indicates a configuration suggestion for the configuration state of the security configuration item; generating a configuration set of the security configuration items of the target service based on the labeling information and the configuration state of the security configuration items; and reconfiguring the security configuration items of the target service according to the configuration set. Through the present disclosure, the reconfigured target service can not only meet actual needs, but also can be maximally tightened unnecessary permissions, thereby solving the problem that the configuration set is difficult to guarantee the security of the target service in the related art.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to a method, apparatus, device, medium, and product for configuring security configuration items for a service. Background Technology

[0002] In systemd-based Linux systems, the security of service processes relies on the per-service security / sandboxing mechanism provided by systemd. This mechanism primarily restricts the service's permission scope through a series of configuration items (such as CapabilityBoundingSet, SystemCallFilter, RestrictAddressFamilies, etc.) to reduce security risks. systemd-analyze security is a core security assessment tool built into systemd. By examining the service's systemd configuration items, it generates a numerical exposure level score from 0.0 to 10.0. A higher score indicates a higher service exposure level, while a lower score indicates stricter sandbox restrictions and a lower exposure level. This tool provides system administrators with a basic reference for assessing service security status and is widely used in Linux deployment scenarios such as servers and embedded devices.

[0003] With the increasing prevalence of Linux systems in critical business scenarios, the appropriateness of service process security configurations directly impacts the overall system security. However, existing systemd security configuration optimizations largely rely on static rule base recommendations or manual adjustments by administrators based on experience. Such methods fail to align with the actual behavior of services, easily leading to issues such as overly lenient permission configurations (large exposure surface, vulnerable to attacks) or overly restrictive configurations (impacting normal service operation), making it difficult to guarantee the security of target services under the "least privilege" configuration set. Summary of the Invention

[0004] This disclosure provides a method, apparatus, device, medium, and product for configuring security configuration items for a service, to at least address the problem in related technologies that it is difficult to guarantee the security of a target service under that configuration set.

[0005] According to a first aspect of the present disclosure, a method for configuring security configuration items of a service is provided, comprising: extracting the configuration status of at least one security configuration item of a target service; for each security configuration item whose configuration status is allowed, determining annotation information of the security configuration item based on the occurrence of the corresponding behavioral characteristics of the security configuration item during the execution of the target service, wherein the annotation information indicates a configuration suggestion for the configuration status of the security configuration item; generating a configuration set of security configuration items of the target service based on the annotation information and configuration status of the security configuration items, wherein the configuration set includes the updated configuration status of the security configuration items according to the configuration suggestion; and resetting the security configuration items of the target service according to the configuration set.

[0006] Optionally, based on the occurrence of the behavioral characteristics corresponding to the security configuration item during the execution of the target service, the annotation information of the security configuration item is determined, including: determining whether the execution of the behavioral characteristics corresponding to the security configuration item requires the execution result of another behavioral characteristic; and determining the annotation information of the security configuration item based on the determined result and the occurrence of the behavioral characteristics corresponding to the security configuration item during the execution of the target service.

[0007] Optionally, based on the determined results and the occurrence of the behavioral characteristics corresponding to the security configuration item during the execution of the target service, the annotation information of the security configuration item is determined, including: in response to the occurrence of the behavioral characteristics corresponding to the security configuration item being a first case and determining that the execution of the behavioral characteristics requires the execution result of another behavioral characteristic, the first annotation information of the security configuration item is determined to be blocked by another behavioral characteristic, wherein the first case is that the behavioral characteristic will definitely appear during the execution of the target service; in response to the occurrence of the behavioral characteristics corresponding to the security configuration item being a second case, the first annotation information of the security configuration item is determined to be adjusted to be disallowed, wherein the second case is that the behavioral characteristic will definitely not appear during the execution of the target service; in response to the occurrence of the behavioral characteristics corresponding to the security configuration item being a third case, or, the occurrence of the behavioral characteristic being a first case and determining that the execution of the behavioral characteristics does not require the execution result of another behavioral characteristic, the behavioral characteristic is input into a large language model to obtain the first annotation information of the security configuration item, wherein the third case is that it is impossible to determine whether the behavioral characteristic appears during the execution of the target service, and the obtained first annotation information is adjusted to be disallowed or pending further review.

[0008] Optionally, when the category of the security configuration item is the system call category, the annotation information of the security configuration item is determined based on the occurrence of the corresponding behavioral feature during the execution of the target service. This further includes: in response to the first situation where the occurrence of the corresponding behavioral feature is as described above and the target service calls any system call during the execution of the behavioral feature, determining the second annotation information of the security configuration item as "maintain allowed"; in response to the second situation where the occurrence of the corresponding behavioral feature is as described above and the execution of the behavioral feature requires the execution result of another behavioral feature, determining the second annotation information of the security configuration item as "blocked by another behavioral feature"; in response to the second situation where the occurrence of the corresponding behavioral feature is as described above and the execution of the behavioral feature does not require the execution result of another behavioral feature, determining the second annotation information of the security configuration item as "adjusted to disallowed"; and in response to the second situation where the occurrence of the corresponding behavioral feature is as described above and there is indirect contact with library functions, determining the second annotation information of the security configuration item as "pending further review." The security configuration item of the system call category is used to manage system call groups and architectural permissions.

[0009] Optionally, before generating the configuration set of security configuration items for the target service based on the annotation information and configuration status of the security configuration items, the method further includes: integrating multiple annotation information of the same security configuration item according to the configuration leniency principle to obtain the integrated annotation information of the security configuration item, wherein the annotation information that is adjusted to be disallowed in the configuration leniency principle is the annotation information that is discarded first, and the multiple annotation information includes the first annotation information and the second annotation information.

[0010] Optionally, at least one of the above security configuration items is divided into the following categories: system call category, where security configuration items are used to manage system call groups and architecture permissions; capability category, where security configuration items are used to manage permissions for kernel capabilities; namespace category, where security configuration items are used to manage namespace creation permissions; address family category, where security configuration items are used to manage address family usage permissions; memory execution category, where security configuration items are used to manage memory write and execute permissions; and file system and mount category, where security configuration items are used to manage file system access and mount permissions.

[0011] Optionally, after resetting the security configuration items of the target service by configuration set, the method further includes: collecting the service logs of the target service after the reset; inputting the service logs into a large language model to obtain the exception information for the target service; in response to the target service running normally and without exception information, using the configuration set as the target configuration set for the target service; in response to the target service running normally and with exception information, or the target service not running normally, re-acquiring the configuration set of the security configuration items until the target service runs normally and without exception information.

[0012] According to a second aspect of the present disclosure, a configuration apparatus for security configuration items of a service is provided, comprising: an extraction unit configured to extract the configuration state of at least one security configuration item of a target service; a determination unit configured to, for each security configuration item whose configuration state is allowed, determine annotation information of the security configuration item based on the occurrence of the corresponding behavioral characteristics of the security configuration item during the execution of the target service, wherein the annotation information indicates a configuration suggestion for the configuration state of the security configuration item; a generation unit configured to generate a configuration set of security configuration items of the target service based on the annotation information and configuration state of the security configuration items, wherein the configuration set includes the updated configuration state of the security configuration items according to the configuration suggestion; and a configuration unit configured to reconfigure the security configuration items of the target service according to the configuration set.

[0013] Optionally, the determining unit is further configured to determine whether the execution of the behavioral feature corresponding to the security configuration item requires the execution result of another behavioral feature; and based on the determined result and the occurrence of the behavioral feature corresponding to the security configuration item in the execution process of the target service, determine the annotation information of the security configuration item.

[0014] Optionally, the determining unit is further configured to, in response to a first condition where the occurrence of the behavioral feature corresponding to the security configuration item is determined and the execution of the behavioral feature requires the execution result of another behavioral feature, determine the first annotation information of the security configuration item as blocked by another behavioral feature, wherein the first condition is that the behavioral feature will definitely appear during the execution of the target service; in response to a second condition where the occurrence of the behavioral feature corresponding to the security configuration item is determined, determine the first annotation information of the security configuration item as adjusted to not allowed, wherein the second condition is that the behavioral feature will definitely not appear during the execution of the target service; in response to a third condition where the occurrence of the behavioral feature corresponding to the security configuration item is determined, or, in the first condition where the occurrence of the behavioral feature is determined and the execution of the behavioral feature does not require the execution result of another behavioral feature, input the behavioral feature into the large language model to obtain the first annotation information of the security configuration item, wherein the third condition is that it is impossible to determine whether the behavioral feature will appear during the execution of the target service, and the obtained first annotation information is adjusted to not allowed or pending further review.

[0015] Optionally, when the category of the security configuration item is a system call category, the determining unit is further configured to: determine the second annotation information of the security configuration item as "maintainable and allowed" in response to the occurrence of the behavior feature corresponding to the security configuration item being a first case and the target service calling any system call when the behavior feature is executed; determine the second annotation information of the security configuration item as "blocked by another behavior feature" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and the execution of the behavior feature requiring the execution result of another behavior feature; determine the second annotation information of the security configuration item as "adjusted to disallowed" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and the execution of the behavior feature not requiring the execution result of another behavior feature; and determine the second annotation information of the security configuration item as "pending further review" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and there being indirect contact with library functions; wherein, the security configuration item of the system call category is used to manage system call groups and architecture permissions.

[0016] Optionally, the generation unit is further configured to integrate multiple annotations of the same security configuration item according to the configuration leniency principle before generating the configuration set of security configuration items for the target service based on the annotation information and configuration status of the security configuration items, so as to obtain the integrated annotation information of the security configuration item. In this case, the annotation information that is adjusted to be disallowed in the configuration leniency principle is the annotation information that is discarded first. The multiple annotation information includes the first annotation information and the second annotation information.

[0017] Optionally, at least one of the above security configuration items is divided into the following categories: system call category, where security configuration items are used to manage system call groups and architecture permissions; capability category, where security configuration items are used to manage permissions for kernel capabilities; namespace category, where security configuration items are used to manage namespace creation permissions; address family category, where security configuration items are used to manage address family usage permissions; memory execution category, where security configuration items are used to manage memory write and execute permissions; and file system and mount category, where security configuration items are used to manage file system access and mount permissions.

[0018] Optionally, the configuration unit is further configured to, after resetting the security configuration items of the target service by configuration set, collect the service logs of the reset target service; input the service logs into a large language model to obtain exception information for the target service; in response to the target service operating normally and without exception information, use the configuration set as the target configuration set of the target service; in response to the target service operating normally and with exception information, or the target service not operating normally, re-acquire the configuration set of the security configuration items until the target service is operating normally and without exception information.

[0019] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute instructions to implement a method for configuring security configuration items of services according to the present disclosure.

[0020] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by at least one processor, causes at least one processor to perform a configuration method for security configuration items of the services according to the present disclosure as described above.

[0021] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement a configuration method for security configuration items of a service according to the present disclosure.

[0022] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: According to the configuration method, apparatus, device, medium, and product of the security configuration items of the service disclosed herein, based on the occurrence of the behavioral characteristics corresponding to the security configuration items, a configuration suggestion, i.e., annotation information, is determined for each security configuration item whose configuration status is allowed. Based on this configuration suggestion and the configuration status of the security configuration items, a new configuration set with minimum permissions can be generated, realizing a "behavior-driven" reverse inference of minimum permissions. Furthermore, since the configuration set is no longer obtained based on a static rule base, redundancy or omissions caused by "rule matching" can be avoided. Therefore, after reconfiguring the security configuration items of the target service according to this new configuration set, the configured target service not only meets actual needs (i.e., satisfies the normal operation requirements of the target service) but also minimizes unnecessary permissions, thereby improving the configuration accuracy of the target service. Therefore, this disclosure solves the problem in related technologies where the obtained configuration set cannot guarantee the security of the target service under that configuration set.

[0023] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0024] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0025] Figure 1 This is a flowchart illustrating a method for configuring security configuration items for a service according to an exemplary embodiment; Figure 2 This is a flowchart illustrating a module interaction process for obtaining a configuration set, according to an exemplary embodiment. Figure 3This is a block diagram illustrating a configuration apparatus for security configuration items of a service according to an exemplary embodiment; Figure 4 This is a block diagram of an electronic device 400 according to an embodiment of the present disclosure. Detailed Implementation

[0026] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0027] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0028] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0029] Currently, the static configuration assessment method centered on the systemd-analyze security tool reads the service's systemd configuration file, extracts security configuration items, and calculates the exposure level based on a built-in fixed scoring model. It can only inform the administrator of the current exposure level of the configuration, but cannot provide specific permission optimization suggestions, let alone deduce the minimum permission configuration based on the assessment results.

[0030] Furthermore, the aforementioned technology also has the following drawbacks: 1) Lack of behavioral support in configuration: Evaluation is based solely on static rules or the configuration itself, without considering the actual behavior of the service (such as system calls, file operations, IPC interactions, etc.). It is impossible to determine which permissions are necessary for the service to run, resulting in the configuration state adjusted based on the evaluation results being either redundant (too loose) or missing (too tight).

[0031] 2) Inaccurate system call filtering configuration: For complex evaluation items such as SystemCallFilter, static rule bases have difficulty accurately determining the "complete allowed list" based on source code behavior. This can lead to either blindly disabling the system, causing service abnormalities, or allowing all related calls to be made, resulting in an excessively large exposure surface.

[0032] 3) Lack of automated reverse engineering capability: Existing solutions mostly rely on manual adjustments, which is inefficient, and the differences in experience among different administrators lead to poor configuration consistency, making it impossible to achieve batch and automated reverse engineering of minimum permission configurations.

[0033] To address the aforementioned issues, this disclosure provides a method for configuring security configuration items for a service. Based on the occurrence of behavioral characteristics corresponding to the security configuration items, a configuration suggestion (i.e., annotation information) is determined for each security configuration item whose configuration status is allowed. Based on the configuration status of the security configuration items with these suggestions, the latest configuration set with minimum permissions can be generated, achieving a "behavior-driven" reverse inference of minimum permissions. Moreover, since the configuration set is no longer obtained based on a static rule base, redundancy or omissions caused by "rule matching" can be avoided. After reconfiguring the security configuration items of the target service according to this latest configuration set, the reset target service not only meets the actual needs, i.e., satisfies the normal operation requirements of the target service, but also tightens unnecessary permissions to the greatest extent, thereby improving the configuration accuracy of the target service. Compared with the prior art, the security assessment accuracy is improved by more than 80%.

[0034] Furthermore, this disclosure provides differentiated reverse logic for three scenarios: "direct tightening," "tightening requiring blocking," and "requiring joint review." This means that based on different situations, corresponding configuration suggestions are given to avoid target service anomalies caused by blindly tightening security configuration items, while mitigating security risks arising from cross-target service privilege transfer. This improves the rationality and security of target service configuration, solves the problem of permission tightening in complex dependency scenarios, and avoids target service anomalies and security risks. Moreover, in the "requiring joint review" scenario, LLM is introduced to achieve intelligent parsing of behavioral features, accurate judgment of complex dependency scenarios, and automatic association of multi-source evidence with configuration items, improving the automation level and accuracy of reverse inference and solving the problems of insufficient adaptation of traditional rule bases and low efficiency of manual parsing. Furthermore, for security configuration items of system call group type, this disclosure combines behavioral characteristics to perform differentiated processing of "reservation, cautious tightening, priority tightening, and weak inference" to balance security and availability, avoiding both blindly disabling security configuration items and causing service abnormalities, and preventing the exposure risks brought about by unrestricted permissions.

[0035] In addition, this disclosure integrates multiple annotation information for the same security configuration item to ensure the uniqueness and rationality of the constraint set, and verifies the configuration set to ensure that the configuration set with the least privileges derived in reverse meets the security tightening requirements without affecting the normal operation of the service.

[0036] It should be noted that the configuration method disclosed herein is applicable to operating systems including, but not limited to, the following: systemd-based Linux desktop operating systems, Linux server operating systems, Linux cloud operating systems, domestically produced Linux distributions, and various systemd-based Linux distributions (such as UOS, deepin, openEuler, Debian, Ubuntu, Red Hat, etc.), with a wide range of application scenarios.

[0037] The configuration method disclosed herein can be applied to, but is not limited to, the following scenarios: enterprise-level security hardening scenarios, i.e., enterprise operations and maintenance teams perform security hardening on systemd services in the production environment, tightening unnecessary permissions to the greatest extent and reducing the service exposure level; third-party vendor service adaptation scenarios, i.e., when enterprises introduce third-party commercial or open-source software and deploy it on their own Linux servers, they verify whether the built-in systemd configuration file has security vulnerabilities, and avoid security risks introduced by third-party servers due to improper configuration.

[0038] The configuration method disclosed herein is applicable to, but not limited to, mainstream package management systems such as dpkg and rpm.

[0039] Hereinafter, with reference to the accompanying drawings, a method, apparatus, device, medium, and product for configuring security configuration items of services according to exemplary embodiments of the present disclosure will be described in detail.

[0040] Figure 1 This is a flowchart illustrating a method for configuring security configuration items for a service according to an exemplary embodiment, such as... Figure 1 As shown, the configuration method for the service's security configuration items includes the following steps: In step 101, the configuration status of at least one security configuration item of the target service is extracted; In step 102, for each security configuration item whose configuration status is allowed, the annotation information of the security configuration item is determined based on the occurrence of the corresponding behavioral characteristics of the security configuration item during the execution of the target service. The annotation information indicates the configuration recommendation for the configuration status of the security configuration item. In step 103, based on the annotation information and configuration status of the security configuration items, a configuration set of security configuration items for the target service is generated, wherein the configuration set includes the configuration status of the security configuration items after being updated according to the configuration recommendations; In step 104, the security configuration items of the target service are reconfigured according to the configuration set.

[0041] As an example, the above configuration status can be either allowed or disallowed. A configuration status of allowed indicates that the security configuration item is configured and the configured value is positive. The configuration value can be true, false, or it can mean removing an item (such as ~AF_NETLINK). A positive configuration value means not disabling or removing the security configuration item, etc. A configuration status of disallowed indicates that the security configuration item is not configured or the security configuration item is configured but the configured value is negative. A negative configuration value means disabling or removing the security configuration item, etc.

[0042] As an example, the above-mentioned behavioral characteristics refer to system operations of the system where the target service resides, such as reading the / etc / myd.conf configuration file, creating the / run / myd.sock socket file, listening to a specific BusName on the system bus, writing data to the / etc directory, modifying the system clock, loading kernel modules, and accessing device nodes, etc. This disclosure does not limit these operations.

[0043] As an example, the configuration status of the aforementioned security configuration items and the occurrence of their corresponding behavioral characteristics during the execution of the target service can be extracted from a pre-obtained or received evaluation report, and this disclosure does not limit this. The aforementioned evaluation report may include, but is not limited to, the following: all systemd security configuration items of the target service, multi-source evidence (source code paths, compilation logs, unit test results, etc.), three types of behavioral facts (such as behavioral characteristics that are certain to occur, behavioral characteristics that are certain to not occur, and behavioral characteristics that may occur), and the configuration status of the security configuration items. This disclosure does not limit the process of obtaining the aforementioned evaluation report.

[0044] After receiving the assessment report, preprocessing is performed, such as filtering invalid security configuration items (e.g., unenabled configuration items); extracting core features related to permission configuration from multi-source evidence; focusing on screening "behavioral features that will definitely not occur" and "behavioral features that will definitely occur" as the core basis for tightening and retaining permissions, respectively; and obtaining behavioral traces related to external helpers and IPC interactions, etc. This disclosure does not limit these aspects.

[0045] As an example, the above three types of behavioral facts indicate the occurrence of the behavioral characteristics corresponding to the security configuration items. Based on the occurrence of the behavioral characteristics corresponding to the security configuration items, the Large Language Model (LLM) can be used to obtain configuration suggestions for the configuration status of the security configuration items. This disclosure does not limit this.

[0046] As an example, you can use the generated minimum privilege configuration set to replace the original systemd configuration file of the target service, execute the systemctl daemon-reload command to reload the configuration, and make the new configuration take effect.

[0047] As an example, the generated configuration set can be accompanied by behavioral evidence and scenario explanations, making the configuration traceable and explainable, facilitating administrator understanding and maintenance. For instance, based on multi-source evidence and corresponding security configuration items, LLM automatically generates explanations for each security configuration item. The content may include, but is not limited to: the reasons for tightening / retaining, corresponding behavioral evidence (such as source code path / compilation logs / call traces), and explanations of special scenarios (such as blocking tightening, linked review, weak inference, etc.). Then, LLM structurally integrates the generated minimum-privilege configuration set with the accompanying explanations, outputting a standardized configuration document in text format. This text format facilitates administrator viewing, application, and subsequent maintenance.

[0048] According to an exemplary embodiment of this disclosure, the step 102 above, which determines the annotation information of a security configuration item based on the occurrence of the behavioral feature corresponding to the security configuration item during the execution of the target service, may include: determining whether the execution of the behavioral feature corresponding to the security configuration item requires the execution result of another behavioral feature; and determining the annotation information of the security configuration item based on the determined result and the occurrence of the behavioral feature corresponding to the security configuration item during the execution of the target service.

[0049] By combining whether the execution of a behavioral feature requires the execution result and occurrence of another behavioral feature, this embodiment can avoid target service anomalies caused by blindly tightening security configuration items, while avoiding security risks caused by cross-target service privilege transfer, and improving the rationality and security of target service configuration.

[0050] According to an exemplary embodiment of this disclosure, in step 102 above, determining the annotation information of a security configuration item based on the determined result and the occurrence of the behavioral feature corresponding to the security configuration item during the execution of the target service may include: in response to the occurrence of the behavioral feature corresponding to the security configuration item being a first case and determining that the execution of the behavioral feature requires the execution result of another behavioral feature, determining the first annotation information of the security configuration item as blocked by another behavioral feature, wherein the first case is that the behavioral feature will definitely appear during the execution of the target service; in response to the occurrence of the behavioral feature corresponding to the security configuration item being a second case, determining the first annotation information of the security configuration item as adjusted to not allowed, wherein the second case is that the behavioral feature will definitely not appear during the execution of the target service; in response to the occurrence of the behavioral feature corresponding to the security configuration item being a third case, or, the occurrence of the behavioral feature being a first case and determining that the execution of the behavioral feature does not require the execution result of another behavioral feature, inputting the behavioral feature into a large language model to obtain the first annotation information of the security configuration item, wherein the third case is that it is impossible to determine whether the behavioral feature will appear during the execution of the target service, and the obtained first annotation information is adjusted to not allowed or pending further review.

[0051] This embodiment provides differentiated reverse logic for three scenarios: "direct tightening," "tightening requiring blocking," and "requiring joint review." Based on different situations, it offers corresponding configuration suggestions to avoid target service anomalies caused by blindly tightening security configuration items, while mitigating security risks associated with cross-target service privilege transfer. This improves the rationality and security of target service configuration, solving the problem of permission tightening in complex dependency scenarios and preventing target service anomalies and security risks. Furthermore, in the "requiring joint review" scenario, LLM is introduced to achieve intelligent parsing of behavioral features, accurate judgment of complex dependency scenarios, and automatic association of multi-source evidence with configuration items. This improves the automation level and accuracy of reverse logic, addressing the problems of insufficient adaptation of traditional rule bases and low efficiency of manual parsing.

[0052] As an example, the differentiated reverse reasoning logic for the three types of scenarios is as follows: 1) Can directly tighten the scene If the behavioral evidence in the assessment report shows that the service has no need to use a certain security configuration item, that is, the behavioral characteristic corresponding to the security configuration item is a "behavioral characteristic that will definitely not occur", then the security configuration item is included in the "candidate tightening" range. In other words, it is inferred that the security configuration item does not need to be enabled and can be disabled or removed from the corresponding configuration. At this time, the labeling information of the security configuration item is adjusted to not allowed.

[0053] For example, if the behavioral evidence in the target service's evaluation report shows that no necessary evidence was found for mlock, hugepage, netlink, raw packet, namespace creation, or mount operations, then the annotation information for security configuration items such as CAP_IPC_LOCK (corresponding to mlock operation), AF_NETLINK, AF_PACKET (corresponding to raw packet), RestrictNamespaces=none (prohibit the creation of all namespaces), and PrivateMounts=yes (enable private mounting and tighten mount permissions) will be determined to be adjusted to be disallowed.

[0054] 2) Scenarios requiring blocking and tightening If the assessment report shows behavioral evidence indicating a special service dependency, such as ExecStartPre=+... (a privileged pre-execution instruction) or external helpers carrying file capabilities, meaning the behavioral characteristic corresponding to the security configuration item is a "certainly occurring behavioral characteristic," then directly tightening the corresponding security configuration item should be prevented. This means the annotation information of the corresponding security configuration item should be determined as another behavioral characteristic for blocking. For example, the corresponding security configuration item can be marked as "blocked by helper" or "blocked by privileged pre-execution instructions," avoiding dependency failure due to direct permission tightening. This scenario fully considers scenarios overlooked by technologies such as external helpers and IPC cross-service privilege transfer, avoiding service anomalies caused by blind tightening, while mitigating security risks from cross-service privilege transfer, thus improving the rationality and security of configuration.

[0055] For example, behavioral evidence in the evaluation report of the target service shows that the ExecStartPre field of the target service contains "+ / usr / libexec / foo-helper" (the "+" indicates execution with privileges), and this helper depends on the CAP_SYS_ADMIN capability. Therefore, direct tightening of CAP_SYS_ADMIN is prevented, and the reason for the block is marked as "depended on by the external helper foo-helper, direct tightening is prohibited".

[0056] 3) Scenarios requiring joint review If the behavioral evidence in the assessment report of the target service shows that the behavioral characteristic corresponding to a certain security configuration item is a "possible behavioral characteristic", or shows that the behavioral characteristic corresponding to the security configuration item is a "certain behavioral characteristic" and the execution of the behavioral characteristic does not require the execution result of another behavioral characteristic, then it is determined to be a scenario that requires joint review.

[0057] For complex scenarios requiring coordinated review, LLM can analyze the behavioral characteristics corresponding to a security configuration item to determine its occurrence. For example, if it is discovered that a target service can request other services to perform privileged operations via IPC (such as D-Bus), the security configuration item cannot be directly determined as "tightenable," meaning it cannot be marked as "adjusted to disallow." Instead, LLM marks it as "requires coordinated review," i.e., "pending further review," and outputs related IPC interaction evidence (such as D-Bus message call fragments and target service speculation) to assist administrators in analyzing the problem. In this embodiment, LLM can accurately identify potential privilege transfer paths by analyzing D-Bus call logic, providing direction for coordinated review.

[0058] It should be noted that the above LLM parsing process can rely on multiple sources of evidence, such as source code paths, compilation logs, unit test results, etc., and this disclosure does not limit it in this regard.

[0059] As an example, behavioral characteristics that meet any of the following conditions can be used for linked review and judgment using LLM: 1) Evidence of relevant behavior regarding D-Bus invocation exists. The source code contains functions such as sd_bus_call, g_dbus_proxy_call, and dbus_send_message; The external symbol table contains D-Bus related symbols; The service, acting as a D-Bus client, sends a message to a service name. 2) Evidence of IPC-related behavior exists Use shared memory, semaphores, message queues, UNIX sockets, etc. for cross-process communication; Interact with other services using commands such as dbus-send and busctl; 3) Evidence of indirect enforcement exists Calling external helpers, scripts, and third-party tools; Dynamically construct and execute commands; Initiating privileged operations indirectly through plugins and dynamic libraries; 4) Dynamic, non-explicit permission behaviors exist. Whether to call high-privilege interfaces is determined at runtime. The behavior of the configuration items does not appear directly in the service code; For example, after LLM parses the source code, it finds that the service can call the dbus_send_message function through D-Bus to request other privileged services to perform mount operations. In this case, LLM marks the corresponding SystemCallFilter=@mount item as "requires joint review" and outputs the source code path and message parameter characteristics of the D-Bus call to assist the administrator in subsequent IPC access policy review.

[0060] According to an exemplary embodiment of this disclosure, when the category of the security configuration item is a system call category, step 102 above, which determines the annotation information of the security configuration item based on the occurrence of the behavioral feature corresponding to the security configuration item during the execution of the target service, may further include: in response to the occurrence of the behavioral feature corresponding to the security configuration item being a first case and the target service calling any system call when the behavioral feature is executed, determining the second annotation information of the security configuration item as "maintain allowed"; in response to the occurrence of the behavioral feature corresponding to the security configuration item being a second case and the execution of the behavioral feature requiring the execution result of another behavioral feature, determining the second annotation information of the security configuration item as "blocked by another behavioral feature"; in response to the occurrence of the behavioral feature corresponding to the security configuration item being a second case and the execution of the behavioral feature not requiring the execution result of another behavioral feature, determining the second annotation information of the security configuration item as "adjusted to disallowed"; in response to the occurrence of the behavioral feature corresponding to the security configuration item being a second case and there being indirect contact with library functions, determining the second annotation information of the security configuration item as "awaiting further review"; wherein, the security configuration item of the system call category is used to manage system call groups and architecture permissions.

[0061] In this embodiment, for security configuration items of system call group type, differentiated processing of "reservation, cautious tightening, priority tightening, and weak inference" is performed in combination with behavioral characteristics to balance security and availability. This avoids service abnormalities caused by blindly disabling security configuration items, and also prevents the exposure risks brought about by unrestricted permissions.

[0062] As an example, for security configuration items related to system calls, since static source code analysis cannot fully prove the "complete allowed list," differentiated inferences based on corresponding behavioral characteristics are necessary to avoid blindly tightening or loosening permissions. For example, taking the SystemCallFilter configuration item as an example, security configuration items are specifically classified as follows: If the behavioral evidence in the assessment report shows that the target service explicitly calls a certain type of system call when executing the behavior characteristic corresponding to the security configuration item (such as the unit path of deepin-anything-server containing modprobe / rmmod, corresponding to kernel module operations), that is, the behavior characteristic corresponding to the security configuration item is a "certainly occurring behavior characteristic" and the target service calls any system call when the behavior characteristic is executed, then the SystemCallFilter_module class (module-related system calls) cannot be blindly disabled and must be retained, that is, the annotation information of the security configuration item is determined to be allowed to remain. Tighten cautiously: If the behavioral evidence in the assessment report shows no direct call traces, but there are potential dependency scenarios (such as the SystemCallFilter_mount class, which has no explicit mount / unmount calls in the code, but may be triggered by external disk refresh, udisks association, helper calls, etc.), that is, the behavioral characteristic corresponding to the security configuration item is a "behavioral characteristic that will definitely not occur" and the execution of the behavioral characteristic requires the execution result of another behavioral characteristic, then it is determined that the annotation information of the security configuration item is blocked by another behavioral characteristic. For example, it can be marked as "No direct mount class call found at present". That is, do not tighten blindly, and it is recommended to combine dynamic verification for confirmation later. Prioritize tightening: If the behavioral evidence in the assessment report shows that there is no usage requirement and no potential dependency risk (such as SystemCallFilter_clock, reboot, swap, cpu_emulation class), that is, the behavioral characteristic corresponding to the security configuration item is a "behavioral characteristic that will definitely not occur" and the execution of the behavioral characteristic does not require the execution result of another behavioral characteristic, then the annotation information of the security configuration item is determined to be adjusted to be disallowed, and it can be prioritized to be included in the tightening scope, and the type of system call is disabled; Weak inference: If the behavioral evidence in the assessment report shows no direct call traces, but there is a possibility of indirect triggering by library functions (such as SystemCallFilter_debug, privileged, resources, raw_io classes), that is, the behavioral characteristics corresponding to the security configuration item are "behavioral characteristics that will definitely not occur" and there is indirect contact with library functions, then the annotation information of the security configuration item is determined to be pending further review. That is, only a weak inference is made, and it is not directly determined to be "tightened". It can be marked as "static inference has no direct requirement, dynamic verification is recommended".

[0063] According to an exemplary embodiment of this disclosure, before generating the configuration set of security configuration items for the target service based on the annotation information and configuration status of the security configuration items in step 103, multiple annotation information of the same security configuration item can be integrated according to the configuration leniency principle to obtain the integrated annotation information of the security configuration item. In this case, the annotation information that is adjusted to be disallowed in the configuration leniency principle is the annotation information that is discarded first. The multiple annotation information includes the first annotation information and the second annotation information.

[0064] This embodiment integrates multiple annotations for the same security configuration item to ensure the uniqueness and rationality of the constraint set.

[0065] As an example, LLM can be introduced to integrate annotation information and generate configuration sets, completely replacing tedious manual operations and improving the efficiency and accuracy of configuration generation. The specific process can be as follows: 1) Intelligent Integration of Labeling Information and Conflict Resolution: The first and second labeling information are input into the LLM (Local Management Module). The LLM automatically integrates the labeling information, intelligently identifying and eliminating conflict constraints according to preset rules. For example, if a security configuration item is marked as both "adjustable to allow" and "blocked by another behavior feature," the LLM automatically integrates the labeling information of that security configuration item and determines it as "blocked by another behavior feature." Simultaneously, redundant labeling information for the same security configuration item is merged to ensure the uniqueness and rationality of the labeling information for each security configuration item. It should be noted that the principle of labeling information integration is a lenient strategy: service availability is ensured first, followed by security hardening; only in this way is security hardening meaningful.

[0066] 2) Standardized configuration set generation: Based on the integrated annotation information, LLM strictly follows the systemd unit configuration syntax and automatically generates a minimum permission configuration set for the target service. The security configuration item format and writing specifications in the configuration set fully match the requirements of the systemd configuration file and can be directly applied to the systemd configuration file of the target service.

[0067] 3) Intelligent generation of configuration explanations: Based on multi-source evidence and corresponding security configuration items, LLM automatically generates explanations for each security configuration item. The content may include, but is not limited to: the reasons for tightening / retaining, the corresponding behavioral evidence (such as source code path / compilation log / call traces, etc.), and special scenario descriptions (such as blocking tightening, linked review, weak inference, etc.).

[0068] 4) Standardized document output: LLM integrates the generated minimum permission configuration set with accompanying explanations in a structured manner, and outputs a standardized configuration document in text format. It supports text format, which is convenient for administrators to view, apply and maintain.

[0069] A sample (fragment) of the configuration set can be generated as follows:

[0070] According to exemplary embodiments of this disclosure, the at least one security configuration item is categorized as follows: system call category, where security configuration items manage system call groups and architecture permissions; capability category, where security configuration items manage permissions for kernel capabilities; namespace category, where security configuration items manage namespace creation permissions; address family category, where security configuration items manage address family usage permissions; memory execution category, where security configuration items manage memory write and execute permissions; and file system and mount category, where security configuration items manage file system access and mount permissions.

[0071] This embodiment divides security configuration items into six categories, including capability category and namespace category, to achieve classified and targeted permission reverse inference, thereby improving the accuracy and efficiency of reverse inference.

[0072] As an example, systemd security configuration items can be divided into the following 6 categories based on permission type. Each category contains specific configuration item examples to ensure that the categories cover all core permission configurations: Capability categories: Centered on CapabilityBoundingSet, it includes various kernel capabilities (such as CAP_IPC_LOCK, CAP_NET_ADMIN, CAP_SYS_MODULE, etc.). The namespace category, centered around RestrictNamespaces, can include namespace creation permissions such as pid, net, and mnt. Address family categories, centered around RestrictAddressFamilies, can include address family usage permissions such as AF_INET, AF_UNIX, AF_NETLINK, and AF_PACKET; The memory execution category, with MemoryDenyWriteExecute as its core, controls memory write and execute permissions through its configuration options. System call categories, which are centered around SystemCallArchitectures and SystemCallFilter, can include various system call groups (such as @mount) and architectural constraints; File system and mount categories, which can include PrivateMounts, ProtectKernelModules, ProtectKernelTunables, ProtectSystem, etc., are used to manage file system access and mount permissions.

[0073] It should be noted that the above six categories can be derived by considering the underlying system resources constrained by different security configuration items and their corresponding behavioral characteristics. This disclosure does not impose any limitations on these categories. The security configuration items in each category are assigned corresponding annotation information in sequence, and the order in which the annotation information is determined for each category is not limited in this disclosure.

[0074] According to an exemplary embodiment of this disclosure, after resetting the configuration status of the security configuration items of the target service by configuration set in step 104 above, the service log of the target service after the reset can also be collected; the service log is input into the large language model to obtain the abnormal information for the target service; in response to the target service running normally and without abnormal information, the configuration set is used as the target configuration set of the target service; in response to the target service running normally and with abnormal information, or the target service not running normally, the configuration set of the security configuration items is re-acquired until the target service runs normally and without abnormal information.

[0075] By verifying the configuration set through this embodiment, it can be ensured that the configuration set with the least privileges obtained by reverse engineering meets the security tightening requirements without affecting the normal operation of the service.

[0076] As an example, LLM can be introduced to achieve intelligent log parsing, automatic fault location, and adaptive configuration adjustment, thus completing efficient verification. The core process can be as follows: 1) Application configuration: Use the generated minimum privilege configuration set to replace the original systemd configuration file of the target service, execute the systemctl daemon-reload command to reload the configuration and make the new configuration take effect; 2) Restart the service: Execute the command `systemctl restart [service name]` to restart the target service using the new minimum privilege configuration set; 3) LLM Intelligent Log Inspection: The service logs of the system where the target service is located are collected by executing the journal, for example, by executing the command journalctl -u [service name] -f to obtain the service logs; then, the LLM automatically parses the contents of the service logs and intelligently identifies various abnormal information such as permission denial and system call interception in the service logs; 4) LLM Result Judgment and Adjustment: If the target service starts normally and LLM does not detect any permission-related errors (no abnormal information), the configuration set of the minimum permissions is deemed to have passed verification and can be formally applied to the production environment; if LLM detects errors during the startup of the target service or permission-related anomalies during operation (such as EPERM permission denial, inability to access ENOENT resources, etc., i.e., abnormal information appears), it automatically determines that the configuration set of the minimum permissions is too strict, and LLM, based on the evidence chain, provides suggested configurations; 5) Iterative optimization: Based on the configuration suggestions given by LLM, such as restoring necessary system call groups and kernel capabilities, relaxing access permissions for corresponding file paths, repeat steps 2) to 4) until the target service can start normally and run stably, and finally determine the optimal set of minimum permissions configuration.

[0077] For example, after restarting deepin-face.service with the least privilege configuration set, check the service logs using journalctl -udeepin-face.service. If a "Permission denied: mlock" error appears, it means that the CAP_IPC_LOCK permission has been excessively tightened. You need to adjust the CapabilityBoundingSet configuration, remove the disabling of CAP_IPC_LOCK, and restart the target service until it is running normally.

[0078] To better understand this disclosure, the following is in conjunction with... Figure 2 Provide a systematic explanation.

[0079] Figure 2 A flowchart illustrating the module interaction process for obtaining a configuration set is shown in Figure 2. This interaction process mainly consists of four core modules, each with the following functions: The front-end data access module is responsible for accessing the evaluation documents for security configuration items, extracting systemd security configuration items, multi-source evidence (such as source code, compilation, installation-related information, etc.), and three types of behavioral facts (i.e., behaviors that are certain to occur, behaviors that are certain to not occur, and behaviors that may occur), as well as preprocessing the data in the evaluation documents to provide a data foundation for subsequent reverse engineering. Evaluation item classification module: Systemd security configuration items are divided into six categories according to permission type, enabling classified and targeted permission reverse inference and improving the accuracy of reverse inference; Least Privilege Deduction Module: Based on three types of behavioral facts and multi-source evidence, it performs differentiated reverse deduction logic on security configuration items under each type to generate annotation information for security configuration items with the least privilege, in order to handle complex dependency scenarios; Configuration generation and output module: Integrates the annotation information of all security configuration items, generates a minimum permission configuration set for the target service, with configuration explanations (such as reasons for tightening, reasons for blocking, etc.), and outputs standardized configuration documents.

[0080] Run the verification module: To ensure that the minimum permission configuration obtained by reverse engineering meets the security tightening requirements without affecting the normal operation of the service, the generated minimum permission configuration set needs to be run and verified. The specific verification process has been described in detail above and will not be elaborated here.

[0081] After successful verification, the configuration set with the minimum permissions will be output.

[0082] In summary, this disclosure uses an assessment report containing a chain of behavioral evidence as a prerequisite. By classifying the configuration items in the assessment report and deriving the annotation information of the least privilege based on the occurrence of behavioral characteristics, it ultimately reverse-engineers the configuration set of the least privilege specific to the service, providing a feasible solution for optimizing the systemd service security sandbox.

[0083] Figure 3 This is a block diagram illustrating a configuration apparatus for security configuration items of a service according to an exemplary embodiment. (Refer to...) Figure 3 The device includes: Extraction unit 30 is configured to extract the configuration status of at least one security configuration item of the target service; determination unit 32 is configured to, for each security configuration item whose configuration status is allowed, determine the annotation information of the security configuration item based on the occurrence of the corresponding behavioral characteristics of the security configuration item during the execution of the target service, wherein the annotation information indicates a configuration suggestion for the configuration status of the security configuration item; generation unit 34 is configured to, based on the annotation information and configuration status of the security configuration items, generate a configuration set of security configuration items of the target service, wherein the configuration set includes the updated configuration status of the security configuration items according to the configuration suggestion; configuration unit 36 ​​is configured to, according to the configuration set, reconfigure the security configuration items of the target service.

[0084] According to an exemplary embodiment of this disclosure, the determining unit 32 is further configured to determine whether the execution of the behavioral feature corresponding to the security configuration item requires the execution result of another behavioral feature; and to determine the annotation information of the security configuration item based on the determined result and the occurrence of the behavioral feature corresponding to the security configuration item in the execution process of the target service.

[0085] By combining whether the execution of a behavioral feature requires the execution result and occurrence of another behavioral feature, this embodiment can avoid target service anomalies caused by blindly tightening security configuration items, while avoiding security risks caused by cross-target service privilege transfer, and improving the rationality and security of target service configuration.

[0086] According to an exemplary embodiment of this disclosure, the determining unit 32 is further configured to, in response to a first situation where the occurrence of the behavioral feature corresponding to the security configuration item is determined and the execution of the behavioral feature requires the execution result of another behavioral feature, determine that the first annotation information of the security configuration item is blocked by another behavioral feature, wherein the first situation is that the behavioral feature will definitely appear during the execution of the target service; in response to a second situation where the occurrence of the behavioral feature corresponding to the security configuration item is determined and the first annotation information of the security configuration item is adjusted to be disallowed, wherein the second situation is that the behavioral feature will definitely not appear during the execution of the target service; in response to a third situation where the occurrence of the behavioral feature corresponding to the security configuration item is determined and the occurrence of the behavioral feature is determined and the execution of the behavioral feature does not require the execution result of another behavioral feature, input the behavioral feature into the large language model to obtain the first annotation information of the security configuration item, wherein the third situation is that it is impossible to determine whether the behavioral feature will appear during the execution of the target service, and the obtained first annotation information is adjusted to be disallowed or pending further review.

[0087] This embodiment provides differentiated reverse logic for three scenarios: "direct tightening," "tightening requiring blocking," and "requiring joint review." Based on different situations, it offers corresponding configuration suggestions to avoid target service anomalies caused by blindly tightening security configuration items, while mitigating security risks associated with cross-target service privilege transfer. This improves the rationality and security of target service configuration, solving the problem of permission tightening in complex dependency scenarios and preventing target service anomalies and security risks. Furthermore, in the "requiring joint review" scenario, LLM is introduced to achieve intelligent parsing of behavioral features, accurate judgment of complex dependency scenarios, and automatic association of multi-source evidence with configuration items. This improves the automation level and accuracy of reverse logic, addressing the problems of insufficient adaptation of traditional rule bases and low efficiency of manual parsing.

[0088] According to an exemplary embodiment of this disclosure, when the category of the security configuration item is a system call category, the determining unit 32 is further configured to: determine the second annotation information of the security configuration item as "maintain allowed" in response to the occurrence of the behavior feature corresponding to the security configuration item being a first case and the target service calling any system call when the behavior feature is executed; determine the second annotation information of the security configuration item as "blocked by another behavior feature" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and the execution of the behavior feature requiring the execution result of another behavior feature; determine the second annotation information of the security configuration item as "adjusted to disallowed" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and the execution of the behavior feature not requiring the execution result of another behavior feature; and determine the second annotation information of the security configuration item as "pending further review" in response to the occurrence of the behavior feature corresponding to the security configuration item being a second case and there being indirect contact with library functions; wherein, the security configuration item of the system call category is used to manage system call groups and architecture permissions.

[0089] In this embodiment, for security configuration items of system call group type, differentiated processing of "reservation, cautious tightening, priority tightening, and weak inference" is performed in combination with behavioral characteristics to balance security and availability. This avoids service abnormalities caused by blindly disabling security configuration items, and also prevents the exposure risks brought about by unrestricted permissions.

[0090] According to an exemplary embodiment of this disclosure, the generation unit 34 is further configured to integrate multiple annotation information of the same security configuration item according to the configuration leniency principle before generating the configuration set of security configuration items of the target service based on the annotation information and configuration status of the security configuration item, so as to obtain the integrated annotation information of the security configuration item, wherein the annotation information that is adjusted to be disallowed in the configuration leniency principle is the annotation information that is discarded first, and the multiple annotation information includes the first annotation information and the second annotation information.

[0091] This embodiment integrates multiple annotations for the same security configuration item to ensure the uniqueness and rationality of the constraint set.

[0092] According to exemplary embodiments of this disclosure, the at least one security configuration item is categorized as follows: system call category, where security configuration items manage system call groups and architecture permissions; capability category, where security configuration items manage permissions for kernel capabilities; namespace category, where security configuration items manage namespace creation permissions; address family category, where security configuration items manage address family usage permissions; memory execution category, where security configuration items manage memory write and execute permissions; and file system and mount category, where security configuration items manage file system access and mount permissions.

[0093] This embodiment divides security configuration items into six categories, including capability category and namespace category, to achieve classified and targeted permission reverse inference, thereby improving the accuracy and efficiency of reverse inference.

[0094] According to an exemplary embodiment of this disclosure, the configuration unit 36 ​​is further configured to: after resetting the configuration status of the security configuration items of the target service by configuration set, collect the service log of the reset target service; input the service log into a large language model to obtain abnormal information for the target service; in response to the target service operating normally and without abnormal information, use the configuration set as the target configuration set of the target service; in response to the target service operating normally and with abnormal information, or the target service not operating normally, re-acquire the configuration set of the security configuration items until the target service operates normally and without abnormal information.

[0095] By verifying the configuration set through this embodiment, it can be ensured that the configuration set with the least privileges obtained by reverse engineering meets the security tightening requirements without affecting the normal operation of the service.

[0096] According to embodiments of this disclosure, an electronic device may be provided. Figure 4 This is a block diagram of an electronic device 400 according to an embodiment of the present disclosure. The electronic device includes at least one memory 401 and at least one processor 402. The at least one memory stores a set of computer-executable instructions. When the set of computer-executable instructions is executed by the at least one processor, a configuration method for security configuration items of a service according to an embodiment of the present disclosure is performed.

[0097] As an example, electronic device 400 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 400 is not necessarily a single electronic device, but may be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 400 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0098] In electronic device 400, processor 402 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 402 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0099] The processor 402 can execute instructions or code stored in memory, wherein memory 401 can also store data. Instructions and data can also be sent and received over a network via a network interface device, wherein the network interface device can employ any known transmission protocol.

[0100] The memory 401 may be integrated with the processor 402, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 401 may include a separate device, such as an external disk drive, a storage array, or other storage device that can be used by any database system. The memory 401 and the processor 402 may be operatively coupled, or may communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 402 to read files stored in the memory 401.

[0101] In addition, the electronic device 400 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0102] According to embodiments of this disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes to perform a configuration method for security configuration items of the services of embodiments of this disclosure. Examples of computer-readable storage media include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0103] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions, and a method for configuring security configuration items that implement the services of this disclosure when the computer instructions are executed by a processor.

[0104] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0105] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for configuring security configuration items for a service, characterized in that, include: Extract the configuration status of at least one security configuration item of the target service; For each security configuration item whose configuration status is allowed, determine whether the execution of the behavior feature corresponding to the security configuration item requires the execution result of another behavior feature; based on the determined result and the occurrence of the behavior feature corresponding to the security configuration item in the execution process of the target service, determine the annotation information of the security configuration item, wherein the annotation information indicates the configuration suggestion for the configuration status of the security configuration item; Based on the annotation information and configuration status of the security configuration items, a configuration set of security configuration items for the target service is generated, wherein the configuration set includes the configuration status of the security configuration items after being updated according to the configuration recommendations; Reconfigure the security configuration items of the target service according to the configuration set; The step of determining the annotation information of the security configuration item based on the determined results and the occurrence of the behavioral characteristics corresponding to the security configuration item during the execution of the target service includes: In response to the occurrence of the behavior feature corresponding to the security configuration item being a first case and determining that the execution of the behavior feature requires the execution result of another behavior feature, the first annotation information of the security configuration item is determined to be blocked by another behavior feature, wherein the first case is that the behavior feature must occur during the execution of the target service; In response to the occurrence of the behavior feature corresponding to the security configuration item being the second case, the first annotation information of the security configuration item is determined to be adjusted to be disallowed, wherein the second case is that the behavior feature will definitely not appear during the execution of the target service; In response to the occurrence of the behavior feature corresponding to the security configuration item being a third case, or the occurrence of the behavior feature being a first case and it is determined that the execution of the behavior feature does not require the execution result of another behavior feature, the behavior feature is input into the large language model to obtain the first annotation information of the security configuration item. In the third case, it is impossible to determine whether the behavior feature appears during the target execution service process, and the obtained first annotation information is adjusted to be not allowed or to be further reviewed.

2. The configuration method as described in claim 1, characterized in that, When the category of the security configuration item is a system call category, determining the annotation information of the security configuration item based on the occurrence of the behavioral characteristics corresponding to the security configuration item during the execution of the target service further includes: In response to the occurrence of the behavior feature corresponding to the security configuration item being the first situation and the target service calling any system call when the behavior feature is executed, the second annotation information of the security configuration item is determined to be "maintain allowed". In response to the occurrence of the behavior feature corresponding to the security configuration item being the second situation and the execution of the behavior feature requiring the execution result of another behavior feature, it is determined that the second annotation information of the security configuration item is blocked by another behavior feature; In response to the occurrence of the behavior feature corresponding to the security configuration item being the second situation and the execution of the behavior feature not requiring the execution result of another behavior feature, the second annotation information of the security configuration item is determined to be adjusted to be disallowed; In response to the occurrence of the behavioral characteristics corresponding to the security configuration item being the second situation and having indirect contact with library functions, the second annotation information of the security configuration item is determined to be pending further review; The security configuration items for the system call category are used to manage system call groups and architecture permissions.

3. The configuration method as described in claim 2, characterized in that, Before generating the configuration set of security configuration items for the target service based on the annotation information and configuration status of the security configuration items, the method further includes: Multiple annotations for the same security configuration item are integrated according to the configuration leniency principle to obtain the integrated annotation information of the security configuration item. Among them, the annotation information that is adjusted to be disallowed in the configuration leniency principle is the annotation information that is discarded first. The multiple annotation information includes first annotation information and second annotation information.

4. The configuration method as described in claim 1, characterized in that, The at least one security configuration item is categorized as follows: System call categories, whose security configuration items are used to manage system call groups and architecture permissions; Capability categories, where security configuration items under these capability categories are used to manage permissions for kernel capabilities; Namespace category, the security configuration items under the namespace category are used to manage namespace creation permissions; Address family categories, where security configuration items under the address family categories are used to manage address family usage permissions; Memory execution category, whose security configuration items are used to manage memory write and execute permissions; File systems and mount categories, whose security configuration items are used to manage file system access and mount permissions.

5. The configuration method as described in claim 1, characterized in that, After reconfiguring the security configuration items of the target service according to the configuration set, the following is also included: Collect the service logs of the target service after the reset; The service logs are input into a large language model to obtain exception information for the target service. If the target service is running normally and there is no abnormal information, then the configuration set is taken as the target configuration set of the target service; In response to the target service operating normally and an abnormal message appearing, or the target service not operating normally, the configuration set of the security configuration items is re-acquired until the target service is operating normally and no abnormal message appears.

6. A configuration device for security configuration items of a service, characterized in that, include: The extraction unit is configured to extract the configuration status of at least one security configuration item of the target service; The determining unit is configured to, for each security configuration item whose configuration state is allowed, determine whether the execution of the behavior feature corresponding to the security configuration item requires the execution result of another behavior feature; based on the determined result and the occurrence of the behavior feature corresponding to the security configuration item in the execution process of the target service, determine the annotation information of the security configuration item, wherein the annotation information indicates a configuration suggestion for the configuration state of the security configuration item; The generation unit is configured to generate a configuration set of security configuration items for the target service based on the annotation information and configuration status of the security configuration items, wherein the configuration set includes the updated configuration status of the security configuration items according to the configuration recommendations; The configuration unit is configured to reconfigure the security configuration items of the target service according to the configuration set; The determining unit is further configured to: respond to a first situation where the occurrence of the behavioral feature corresponding to the security configuration item is a first situation and it is determined that the execution of the behavioral feature requires the execution result of another behavioral feature, determine that the first annotation information of the security configuration item is blocked by another behavioral feature, wherein the first situation is that the behavioral feature will definitely appear during the execution of the target service; respond to a second situation where the occurrence of the behavioral feature corresponding to the security configuration item is a second situation, determine that the first annotation information of the security configuration item is adjusted to be disallowed, wherein the second situation is that the behavioral feature will definitely not appear during the execution of the target service; respond to a third situation where the occurrence of the behavioral feature corresponding to the security configuration item is a third situation, or, where the occurrence of the behavioral feature is the first situation and it is determined that the execution of the behavioral feature does not require the execution result of another behavioral feature, input the behavioral feature into a large language model to obtain the first annotation information of the security configuration item, wherein the third situation is that it is impossible to determine whether the behavioral feature appears during the execution of the target service, and the obtained first annotation information is adjusted to be disallowed or pending further review.

7. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the configuration method for the security configuration items of the service as described in any one of claims 1 to 5.

8. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the processor to perform a configuration method for the security configuration items of the service as described in any one of claims 1 to 5.

9. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement a configuration method for the security configuration items of the service as described in any one of claims 1 to 5.

Images