System authority control method and system based on namespace and storage medium

Abstract

The invention discloses a namespace-based system authority control method and system and a storage medium, and the method comprises the steps: obtaining a namespace to which a current process of a system belongs; judging whether the namespace is a root namespace when a current system is started or not, if not, refusing execution of the process, and if yes, judging whether a file operated by the current process is a preset path file name or not; when the operated file is the preset path file name, refusing the execution of the process, otherwise, allowing the execution of the process; and finally, starting an exception detection mechanism of the system, judging whether the process is in a preset exception mode or not, and if so, executing a rollback operation and recording a log. According to the method, the technical problem that other users of the whole server are affected due to the fact that a cloud mobile phone enterprise user cannot randomly modify the core parameters of the operating system of the server even if the cloud mobile phone enterprise user has a system-level account can be solved.

Description

Technical Field

[0001] This invention relates to the fields of virtualization technology and computer operating system application and management technology, specifically to a system permission control method, system, and storage medium based on namespaces. Background Technology

[0002] Modern people's daily lives are inseparable from mobile phones. Not only can many aspects of life be accomplished on mobile phones, but even many tasks rely on them. With the rapid development of the mobile internet and the maturity of cloud computing and virtualization technologies, coupled with the emergence of personal application needs (such as running multiple instances of mobile games) and enterprise application needs (such as mobile application testing and multi-instance operation, digital marketing, and social media account matrix operation), the demand for cloud mobile phone services has shown a rapid growth trend in recent years.

[0003] The provision of cloud phone services primarily involves using virtualization technology to create multiple virtual spaces on a server's operating system (typically the open-source Linux system). Each virtual space is equivalent to a cloud phone. Depending on the server's processing power, each server can virtualize dozens or even hundreds of cloud phones. These cloud phones are provided to different users. Although users have different cloud phones (isolated at the user level), they all share the same server hardware resources and operating system environment. If any user modifies operating system-level parameters, it will not only affect themselves but also all other users on that server. Furthermore, if the parameters are modified improperly, the server may crash, forcing all users to stop their services, resulting in incalculable catastrophic consequences.

[0004] To address the aforementioned issues, the industry-standard practice is to strictly control account permissions, disallowing users from having access to or modification of operating system parameters. This approach is feasible for individual users, but clearly impractical for enterprise users, especially mobile application testing vendors (who are often large clients of cloud phone services). Firstly, mobile application testing involves many aspects and often requires system-level account support, which allows modification of core system parameters (typically root privileges on Linux). Secondly, these vendors often possess technical development capabilities; even if cloud phone service providers control permissions at the application layer through permission management programs or built-in system management programs, these vendors can still bypass or even crack these permission management programs to directly obtain system-level permissions. Summary of the Invention

[0005] The main objective of this invention is to provide a system permission control method, system, and storage medium based on namespaces, aiming to solve the technical problem mentioned in the background art where cloud phone enterprise users with system-level accounts can arbitrarily modify the core parameters of the server operating system, affecting the entire server.

[0006] To achieve the above objectives, the present invention provides a system access control method based on namespaces, wherein the system is configured with several virtual containers, and the virtual containers are configured with several namespaces, including: S1: Get the namespace of the current process in the system; S2: Determine whether the namespace is the root namespace when the current system starts. If so, jump to S3; otherwise, reject the execution of the process and jump to S4. S3: Determine whether the object being operated on by the current process is a preset path or filename; if the object being operated on is a preset path or filename, then reject the execution of the process; otherwise, allow the execution of the process. S4: Activate the system's anomaly detection mechanism and determine whether the process is in a preset anomaly mode. If so, perform a rollback operation and record the log.

[0007] Optionally, before rejecting the execution of the process, step S2 further includes: S21: Obtain orphan processes in the namespace of the current process and determine whether an orphan process exists; otherwise, jump to S3; if so, reject the execution of the process.

[0008] Optionally, before rejecting the execution of the process in step S21, the method further includes: S22: Obtain the domain name value of the current virtual container and determine whether the domain name value is a host identifier in the system's local network environment; otherwise, proceed to S3; otherwise, reject the execution of the process.

[0009] Optionally, before rejecting the execution of the process, step S22 further includes: S23: Obtain the operation object of the current process and determine whether the operation object is a device object or file object actually stored on the device; otherwise, jump to S3; otherwise, reject the execution of the process.

[0010] Optionally, before rejecting the execution of the process in step S23, the method further includes: S24: Obtain the file name of the operation file of the current process, and determine whether the memory storage required by the operation file name is the preset memory storage space size; otherwise, jump to S3, otherwise reject the execution of the process.

[0011] Optionally, after S3 is executed and before S4 is executed, it further includes determining whether the namespace to which the current process belongs has changed. If so, the execution of the process is rejected; otherwise, the execution of the process is allowed.

[0012] Optionally, the system may also record operation information of the process for system administrators to perform system maintenance and information auditing. The operation information includes timestamp, container ID, PID, and parameter name.

[0013] Optionally, when the operation of the process is reading, the rejection of the process execution is changed to returning a preset virtualization configuration value, and the permission of the process execution is changed to returning the real configuration value of the system.

[0014] This invention also proposes a namespace-based system access control system, comprising: The information acquisition module is used to obtain the namespace to which the current process of the system belongs; The first judgment module is used to determine whether the namespace is the root namespace when the current system starts. If it is, it jumps to the second judgment module; otherwise, it rejects the execution of the process and jumps to the exception handling module. The second judgment module is used to determine whether the file operated on by the current process is a preset path and file name; if the file operated on is a preset path and file name, the execution of the process is rejected; if the file operated on is not a preset path and file name, the execution of the process is allowed. The exception handling module is used to activate the system's exception detection mechanism and determine whether the process is in a preset exception mode. If so, it performs a rollback operation and records the log.

[0015] The present invention also proposes a computer-readable storage medium storing a program for a namespace-based system access control method, the program implementing the namespace-based system access control method.

[0016] The technical solution of this invention identifies and judges the system process attributes and operation instructions in the server's operating system kernel, especially those processes that affect parameters and settings globally. Based on the judgment content and logic designed in this technical solution, it allows or denies their execution, or even returns system virtual parameter values, thereby achieving kernel parameter isolation in a virtual machine environment. This isolation method is unaffected by whether the user has system management privileges, nor by whether the system application layer has permission restrictions. Because any access to or modification of a system parameter ultimately translates into a kernel process in the computer operating system, which is then executed by the CPU (Central Controller). By capturing these processes and controlling their subsequent execution, the technical problem mentioned in this solution can be solved: cloud phone enterprise users arbitrarily modifying server operating system kernel parameters, affecting the entire server.

[0017] For cloud phone service providers and operators, the technical solution of this invention not only ensures the normal and stable operation of servers or server clusters and enables on-demand allocation of resources among cloud phone users, but also effectively inhibits illegal cloud phone technology users from using technical means to arbitrarily modify system configurations to maximize their personal interests while harming the interests of other users, or even using malicious software to frequently modify kernel parameters to damage the system. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the structures shown in these drawings without creative effort.

[0019] Figure 1 A virtualization system architecture diagram of the Linux operating system provided for embodiments of this application; Figure 2 A flowchart of a namespace-based system access control method provided for embodiments of this application; Figure 3 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 4 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 5 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 6A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 7 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 8 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 9 A flowchart of another namespace-based system access control method provided for embodiments of this application; Figure 10 A schematic diagram of a namespace-based system access control system architecture provided for embodiments of this application; The objectives, features, and advantages of this invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0020] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention.

[0021] It should be noted that if the embodiments of the present invention involve directional indicators (such as up, down, left, right, front, back, etc.), the directional indicators are only used to explain the relative positional relationship and movement of the components in a certain specific posture (as shown in the figure). If the specific posture changes, the directional indicators will also change accordingly.

[0022] Furthermore, if the embodiments of this invention involve descriptions such as "first" or "second," these descriptions are for descriptive purposes only and should not be construed as indicating or implying their relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first" or "second" may explicitly or implicitly include at least one of those features. Additionally, the meaning of "and / or" throughout the text includes three parallel solutions; for example, "A and / or B" includes solution A, solution B, or a solution where both A and B are satisfied simultaneously. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by this invention.

[0023] The technical solution of this invention is mainly applied to cloud mobile phone virtual services, where the operating system on the server is Linux. Linux is an open-source operating system, and its underlying code and management settings are open to anyone.

[0024] The Linux operating system achieves efficient resource utilization and isolation through virtualization and containerization technologies. Namespaces are one of the core mechanisms used to provide logical isolation, while containerization relies on namespaces and cgroups (control groups) to encapsulate applications and their dependencies.

[0025] This embodiment provides a namespace-based system access control method, applicable to server systems configured with multiple virtual containers. The virtualization system architecture diagram of the Linux operating system is shown below. Figure 1 As shown, each virtual container has an independent namespace (such as PID namespace, network namespace, mount namespace, IPC namespace, UTS namespace, user namespace, etc.), while a process is the smallest execution unit of the system. This method achieves forced isolation of access to critical system parameters through kernel-level process interception and judgment mechanisms.

[0026] Example 1: like Figure 2 As shown, a system access control method based on namespaces is described. The system is configured with several virtual containers, and each virtual container has several namespaces. The method includes the following steps: S1: Get the namespace of the current process in the system.

[0027] When a process in the system initiates an access request to a system file or parameter (such as through system calls like open(), read(), or write()), the kernel intercepts the request and calls the information acquisition module to obtain the namespace identifier of the process. The namespace identifier can be found in / proc / <pid>Symbolic links in the / ns / directory or kernel interfaces such as ioctl() and ns_get_parent can be obtained.

[0028] The namespaces supported by Linux systems include the following: Mount Namespace UTS Namespace (Hostname and Domain Name Space) IPC Namespace (Inter-Process Communication Namespace) Network Namespace PID Namespace User Namespace This embodiment uses PIN Namespace (process ID namespace) as an example to describe the implementation process of this technical solution.

[0029] Get the namespace of the current process's PID, for example, ns = task_active_pid_ns(curent).

[0030] S2: Determine whether the namespace is the root namespace when the current system starts. If so, jump to S3; otherwise, reject the execution of the process and jump to S4.

[0031] The system receives a namespace identifier and compares it with the root namespace identifier (initial namespace) recorded during system startup. If they match, it means the process is running in the root namespace (i.e., the host system environment), which meets the design's modification-allowed logic. However, whether it can be modified still needs to meet the conditions of the next step, so the process jumps to step S3. If they do not match, it means the process is running in a virtual container or other namespaces outside of this namespace. This process does not belong to the host system environment and is very likely to belong to other containers or other namespaces outside of this namespace. Therefore, the execution of this process needs to be rejected directly, and the process jumps to step S4 for exception handling.

[0032] The determination is made using computer memory addresses, specifically by comparing the memory address of the currently active process's PIN namespace with the memory address of the first root PIN namespace when the Linux system boots. For example, is `task_active_pid_ns` equal to `&init_pid_ns`? Here, "&" represents the address-of operator, and `init_pid_ns` is the first root PIN namespace when the Linux system boots.

[0033] One of the implementation methods is as follows: struct sysctl_namespace_policy { const char *sysctl path; / / Parameter path enum ns_access_level { NS_ACCESS_INIT_ONLY, / / Accessible only by the init namespace NS_ACCESS_ALL, / / Accessible to all namespaces NS_ACCESS_GROUP, / / Accessible within the namespace group NS_ACCESS_LIMITED / / Restricted access (with quota) access_level; pid_namespace_t *allowed_ns; / / The namespaces that are allowed to be accessed int (*validate_callback)(struct pid_namespace *ns, void *value); }

[0034] S3: Determine whether the object being operated on by the current process is a preset path or filename; if the object being operated on is a preset path or filename, then reject the execution of the process; otherwise, allow the execution of the process.

[0035] This step primarily checks whether the files being operated on by the process are protected paths and files. These paths are typically core parameters of the Linux operating system, and this technical solution is designed as a configurable list for system administrators. For example, this list can be configured to include: / proc / sys / (kernel parameter directory) / sys / (System Devices and Parameters Directory) The configuration files in / etc / sysctl.conf and / etc / sysctl.d / Other critical system file paths defined by the system administrator.

[0036] For example, system files, such as those in the / proc / sys / fs / inotify / directory, contain kernel parameters for the Linux inotify mechanism, which are used to control file system monitoring behavior and resource limits.

[0037] ` / proc / sys / fs / inotify / max_queued_events` represents the maximum number of events that can be queued per inotify instance. Events exceeding this value are dropped, but an `IN_Q_OVERFLOW` event is sent. The system default value is 16384.

[0038] ` / proc / sys / fs / inotify / max_user_instances` represents the maximum number of inotify instances that each user can create, which is the number of times `inotify_init()` is called. The system default value is 128. Increasing these values ​​will consume more system kernel memory.

[0039] ` / proc / sys / fs / inotify / max_user_watches` represents the maximum number of file / directory watchpoints that each user can set, which is the total number of `inotify_add_watch()` calls. This is one of the most frequently adjusted parameters in Linux systems, especially when monitoring a large number of files.

[0040] The aforementioned paths and parameters are crucial for managing and optimizing file monitoring, directly impacting system operation globally, and are therefore included in the evaluation criteria. These paths and parameters can also be configured and adjusted according to the system administrator's management or operational needs.

[0041] If the preset path or filename is met, the execution of the process is rejected; otherwise, the execution of the process is allowed.

[0042] One of the implementation methods is as follows: static struct sysctl_namespace_policy sysctl_policies[ ] = { { .sysctl_path = "fs / inotify / max_user_watches", / / Example: path or file 1 Adjustable but limited parameter .access_level = NS_ACCESS_INIT_ONLY, .allowed_ns =&init_pid_ns, .validate_callback = validate_inotify_watch_limit }, { .sysctl_path = "kernel / threads-max", / / Example: path or file 2 Adjustable but limited parameter .access_level = NS_ACCESS_INIT_ONLY, .allowed_ns =&init_pid_ns, .validate_callback = NULL }, { .sysctl_path = "vm / swappiness", / / Example: Container adjustable but limited parameter .access_level = NS_ACCESS_LIMITED, .allowed_ns = NULL, .validate_callback = validate_swappiness_range }, } Due to the complexity of the Linux operating system, any modification or adjustment to the system requires the system's own safeguards to ensure safety and reliability. Therefore, the next step will invoke the system's anomaly detection mechanism.

[0043] S4: Activate the system's anomaly detection mechanism, and determine whether the process is in a preset anomaly mode. If so, perform a rollback operation to restore the system to the default or safe value, record the log, and trigger the alarm mechanism.

[0044] Common system exception patterns include memory exceptions (such as Out Of Memory), file system parameter exceptions (such as Too many open files), network parameter exceptions (such as Cannot assign requested address), process and scheduling exceptions (such as fork: Cannot allocate memory), disk I / O parameter exceptions (such as high I / O latency), exceptions caused by security parameters, and exceptions specific to container / virtualization environments. These are specific mechanisms inherent to the Linux system and will not be elaborated upon here.

[0045] By implementing the above technical solution, and through a system kernel-level process interception and judgment mechanism, mandatory isolation of access to critical system parameters is achieved. This is independent of whether the user has administrator privileges. Any access to or modification of critical system kernel parameters can be identified at the system's underlying kernel process, and access can be allowed or denied. This effectively solves the technical problem of cloud phone users arbitrarily modifying server operating system core parameters, which can affect or threaten the entire server. It also further inhibits unscrupulous cloud phone users from using technical means to arbitrarily modify system configurations to maximize their personal interests at the expense of other users, or even from using malicious software to frequently modify kernel parameters to damage the system.

[0046] Example 2: like Figure 3 As shown, to further enhance the process judgment of system-level parameter adjustments, more refined judgment will be performed on processes that are not in the root namespace at the current system startup. Based on Embodiment 1, an additional judgment step is added: before rejecting the execution of the process in step S2, the following steps are also included: S21: Obtain orphan processes in the namespace of the current process and determine whether an orphan process exists; otherwise, jump to S3; if so, reject the execution of the process.

[0047] An orphan process is a process whose parent process has terminated or exited, but whose child process is still running. When the parent process exits, the child process is adopted by the system init process, typically PID 1 or systemd (in Linux systems). Normally, the parent process waits for the child process to terminate. However, orphan processes may occur in the following situations: The parent process creates the child process; The parent process exits before the child process; The child process loses its parent process and is adopted by init or systemd. The child process continues to run until it completes.

[0048] The advantage of designing orphan processes in Linux systems lies in decoupling the process lifecycle, allowing the child process to continue its work after the parent process exits. This is commonly used in server daemons and background tasks. However, the potential risks are also obvious: if an orphan process enters an infinite loop or encounters an exception, it will continuously consume the system's CPU and memory, potentially causing a disaster for the entire server host.

[0049] If an orphan process exists in the active PID namespace of the current process, it indicates that the container may be in an abnormal state (such as process leakage or malicious resident status), suggesting a potential risk of continuous CPU and memory consumption in the current system. In this case, the execution of the process is rejected. If no orphan process exists and there is no immediate risk of resource consumption in the current system, the process proceeds to the next step.

[0050] One method for identifying orphan processes is: Determine if the PID of the child_reaper under active_pid_ns is greater than 1.

[0051] Using the technical solution of this embodiment, it is possible to ensure that resources are not occupied or excessively consumed from a system perspective, and further solve the technical problem that cloud phone enterprise users arbitrarily modifying the core parameters of the server operating system can bring impact or hidden dangers to the entire server.

[0052] Example 3: like Figure 4 As shown, to further enhance the process judgment of system-level parameter adjustment, based on Embodiment 2, S21 includes the following enhanced judgment steps before rejecting the execution of the process: S22: Obtain the domain name value of the current virtual container and determine whether the domain name value is a host identifier in the system's local network environment; otherwise, proceed to S3; otherwise, reject the execution of the process.

[0053] One way to obtain the domain name of the current virtual container is: Through the / proc / sys / kernel / domainname or uname system call.

[0054] If the domain name value is a host identifier in the system's local network environment, it indicates that the container may be attempting to impersonate the host system, and the execution of the process should be rejected; otherwise, proceed to the next step.

[0055] One method to determine whether a host identifier is located in the system's local network environment is as follows: strmcmp(uts_ns domain_name, "localdomain", 11) = 0 ? Here, strmcmp means to get the string length for comparison, and the number 11 represents the string length.

[0056] Using the technical solution of this embodiment, it is possible to detect processes that disguise themselves as host systems, prevent unauthorized modification and settings of the system, and further solve the technical problem that cloud phone enterprise users may maliciously modify the core parameters of the server operating system, which may bring impact or hidden dangers to the entire server.

[0057] Example 4: like Figure 5 As shown, to further enhance the process judgment of system-level parameter adjustment, based on Embodiment 3, S22 includes a judgment step to check the authenticity of the operation object before rejecting the execution of the process: S23: Obtain the operation object of the current process and determine whether the operation object is a device object or file object actually stored on the device; otherwise, jump to S3; otherwise, reject the execution of the process.

[0058] To obtain the operation object of the current process, you can use `stat()` to check if the device number `st_dev` belongs to the host storage device. If the operation object is a memory file system (such as `tmpfs`, `procfs`) or a virtual device, it may be a temporary or forged object, and you can proceed to the next step; if it is a real device object, execution will be refused.

[0059] One method to determine whether the operation object is a device object or file object actually stored on the device is: Is st_dev or dev greater than 0? If dev is greater than 0, it means that the object operated by the process is a real object; if dev is equal to 0, it means that the object operated by the process is a virtual object or a network node.

[0060] Using the technical solution of this embodiment, protection can be further implemented on real objects of the operating system (such as memory, hard disk storage files, etc.) to prevent unauthorized modification and setting of system memory or files, and further solve the technical problem that cloud phone enterprise users may maliciously modify the core parameters of the server operating system, which may bring impact or hidden dangers to the entire server.

[0061] Example 5: like Figure 6 As shown, to further enhance the process judgment of system-level parameter adjustment, based on Embodiment 4, S23 further includes the following step before rejecting the execution of the process: S24: Obtain the file name of the operation file of the current process, and determine whether the memory storage required by the operation file name is the preset memory storage space size; otherwise, jump to S3, otherwise reject the execution of the process.

[0062] Obtain the filename currently being processed by the process and estimate its required memory storage space. The file size can be obtained using `fstat()`. If the required memory exceeds a preset threshold, it indicates a potential memory exhaustion attack, and the process's execution is rejected; otherwise, proceed to the next step.

[0063] One method to determine whether the memory storage required for the operation file name is within the preset memory storage space size is as follows: strncmp(d_name.name, d_iname, length) = 0 ? Here, strmcmp means to get the string length for comparison, and d_name.name means the file name of the current process.

[0064] Using the technical solution of this embodiment, the rationality of memory usage can be checked, and the technical problem that cloud phone enterprise users may maliciously modify the core parameters of the server operating system, which may bring impact or hidden dangers to the entire server can be further solved.

[0065] Example 6: like Figure 7 As shown, in order to further enhance the process judgment of system-level parameter adjustment, after S3 is executed and before S4 is executed, step S31 is also included: determine whether the namespace to which the current process belongs has changed. If so, reject the execution of the process; otherwise, allow the execution of the process.

[0066] This step is primarily used to detect namespace changes and requires real-time monitoring. When the namespace to which the process belongs changes, it indicates a namespace switch, meaning the process is not operating on resources within this namespace, posing a risk of privilege exceeding permissions. In this case, subsequent operations by the process are denied. Otherwise, the process is allowed to execute.

[0067] One way to determine whether the namespace to which the current process belongs has changed is: ns =&init _pid_ns ? where "&" represents the address-of operator for memory addresses.

[0068] Using the technical solution of this embodiment, the technical problem of avoiding the potential impact or hidden dangers on the entire server caused by cloud phone enterprise users maliciously modifying the core parameters of the server operating system can be further enhanced.

[0069] Example 7: like Figure 8 As shown, to monitor process execution information and meet the needs of subsequent maintenance, after process execution, the system also records the process's operation information for system administrators' system maintenance and information auditing. This operation information includes a timestamp, container ID, PID, parameter name, old value before execution, new value after execution, and operation result. This information is also written to the kernel circular buffer.

[0070] One method for recording the operation information of the process is: struct sysctl audit record { struct pid namespace *pid ns; / / Namespace of the modifier char path

[256] ; / / Parameter path unsigned long old_value; / / old value unsigned long new_value; / / new value struct timespec timestamp; / / Modified time uid_t uid; / / Operator UID bool rollback_possible; / / Whether rollback is possible struct list_head list; } Using the technical solution of this embodiment, the recording information of process operations can be further improved, bringing positive benefits to the maintenance system of cloud phone service providers. For example, it can track user / process behavior, monitor user access to sensitive files, investigate security incidents, and, after an intrusion occurs, the audit log formed by the recorded information can trace the attack path, determine the scope of impact, and find key evidence of intrusion traces. In addition, it can meet compliance requirements, as many industry standards now require the auditing and logging of privileged operations.

[0071] Example 8: When the process's operation is a read operation, denying the process's execution changes to returning a preset virtualization configuration value, and allowing the process's execution changes to returning the system's actual configuration value, such as... Figure 9 As shown. Although read operations pose a low risk to the system, some core system parameters are not suitable for exposure to the user level for certain access control or server operating system maintenance and management needs. Therefore, this technical solution was designed, where the virtualization configuration values ​​can be flexibly configured by system maintenance personnel as needed.

[0072] One embodiment of this technical solution is as follows: / / Provide a virtual / proc / sys view for containers static ssize_t virtual_sysctl_read( struct file *file, char _user *buf, size_t count, loff_t *ppos ) { struct container_sysctl_context *ctx; struct pid_namespace *ns = task_active_pid_ns(current); / / 1. Get the container context ctx = get_container_context(ns); if(!ctx){ / / Revert to the original read return original_sysctl_read(file, buf, count, ppos); } / / 2. Check if it is a virtualization parameter const char *path = get_sysctl_path(file); unsigned long virtual_value; If (get_virtual_value(ctx,path,&virtual_value)) { / / 3. Return virtual value char value_str

[32] ; snprintf(value_str,sizeof(value_str),"%lu\n",virtual_value); return simple_read_from_buffer(buf, count, ppos, value_str, strlen(value_str)); } / / 4. Return the actual value return original_sysctl_read(file, buf, count, ppos); } The foregoing primarily describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the aforementioned functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the method steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0073] This application embodiment can divide the system into functional modules based on the above method example. For example, each function can be divided into its own functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents one logical functional division; other division methods may be used in actual implementation.

[0074] Figure 10 This is a schematic diagram of a namespace-based system access control system provided in an embodiment of this application. The system includes an information acquisition module 110, a first judgment module 111, a second judgment module 112, and an exception handling module 113. Wherein: Information acquisition module 110 is used to acquire the namespace to which the current process of the system belongs; The first judgment module 111 is used to determine whether the namespace is the root namespace when the current system starts. If it is, it jumps to the second judgment module; otherwise, it rejects the execution of the process and jumps to the exception handling module. The second judgment module 112 is used to determine whether the file operated by the current process is a preset path file name; when the file operated is a preset path file name, the execution of the process is rejected; when the file operated is not a preset path file name, the execution of the process is allowed. The exception handling module 113 is used to start the system's exception detection mechanism and determine whether the process is in a preset exception mode. If so, it performs a rollback operation and records the log.

[0075] Optionally, the first judgment module 111 is also used to obtain orphan processes in the namespace to which the current process belongs, and to determine whether there are any orphan processes.

[0076] Optionally, the first judgment module 111 is further configured to obtain the domain name value of the current virtual container and determine whether the domain name value is a host identifier in the local network environment of the system.

[0077] Optionally, the first judgment module 111 is further configured to obtain the operation object of the current process and determine whether the operation object is a device object or a file object actually stored on the device.

[0078] Optionally, the first judgment module 111 is further used to obtain the operation file name of the current process and determine whether the memory storage required by the operation file name is the preset memory storage space size.

[0079] Optionally, the first judgment module 111 is also used to determine whether the namespace to which the current process belongs has changed.

[0080] This application also provides a computer-readable storage medium storing instructions. When a computer executes these instructions, the computer performs each step of the method flow shown in the above-described method embodiments.

[0081] Embodiments of this application provide a computer program product containing instructions that, when executed on a computer, cause the computer to perform the system access control method described in the above method embodiments.

[0082] The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), registers, hard disks, optical fibers, compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing, or any other form of computer-readable storage medium in the art. An exemplary storage medium is coupled to a processor, enabling the processor to read information from and write information to the storage medium. Of course, the storage medium may also be a component of the processor. The processor and the storage medium may reside in an application-specific integrated circuit (ASIC). In the embodiments of this application, the computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0083] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural transformations made using the contents of the specification and drawings of the present invention under the inventive concept of the present invention, or direct / indirect applications in other related technical fields, are included within the scope of patent protection of the present invention.< / pid>

Claims

1. A system access control method based on namespaces, wherein the system is configured with several virtual containers, and the virtual containers are configured with several namespaces, characterized in that, include: S1: Get the namespace of the current process in the system; S2: Determine whether the namespace is the root namespace when the current system starts. If so, jump to S3; otherwise, reject the execution of the process and jump to S4. S3: Determine whether the object being operated on by the current process is a preset path or filename; if the object being operated on is a preset path or filename, then reject the execution of the process; otherwise, allow the execution of the process. S4: Activate the system's anomaly detection mechanism and determine whether the process is in a preset anomaly mode. If so, perform a rollback operation and record the log.

2. The system access control method as described in claim 1, characterized in that, Before rejecting the execution of the process, step S2 further includes: S21: Obtain orphan processes in the namespace of the current process and determine whether an orphan process exists; otherwise, jump to S3; if so, reject the execution of the process.

3. The system access control method as described in claim 2, characterized in that, Before rejecting the execution of the process, step S21 further includes: S22: Obtain the domain name value of the current virtual container and determine whether the domain name value is a host identifier in the system's local network environment; otherwise, proceed to S3; otherwise, reject the execution of the process.

4. The system access control method as described in claim 3, characterized in that, Before rejecting the execution of the process, step S22 further includes: S23: Obtain the operation object of the current process and determine whether the operation object is a device object or file object actually stored on the device; otherwise, jump to S3; otherwise, reject the execution of the process.

5. The system access control method as described in claim 4, characterized in that, Before rejecting the execution of the process, step S23 further includes: S24: Obtain the file name of the operation file of the current process, and determine whether the memory storage required by the operation file name is the preset memory storage space size; otherwise, jump to S3, otherwise reject the execution of the process.

6. The system access control method as described in claim 1, characterized in that, After S3 is executed and before S4 is executed, it is further included to determine whether the namespace to which the current process belongs has changed. If so, the execution of the process is rejected; otherwise, the execution of the process is allowed.

7. The system access control method as described in claim 6, characterized in that, It also includes recording the operation information of the process for system administrators to perform system maintenance and information auditing. The operation information includes timestamp, container ID, PID, and parameter name.

8. The system access control method as described in any one of claims 1-7, characterized in that, When the operation of the process is reading, the rejection of the process execution becomes returning a preset virtualization configuration value, and the permission of the process execution becomes returning the system's real configuration value.

9. A namespace-based system access control system, characterized in that, include: The information acquisition module is used to obtain the namespace to which the current process of the system belongs; The first judgment module is used to determine whether the namespace is the root namespace when the current system starts. If it is, it jumps to the second judgment module; otherwise, it rejects the execution of the process and jumps to the exception handling module. The second judgment module is used to determine whether the object operated by the current process is a preset path or file name; if the object operated on is a preset path or file name, the execution of the process is rejected; otherwise, the execution of the process is allowed. The exception handling module is used to activate the system's exception detection mechanism and determine whether the process is in a preset exception mode. If so, it performs a rollback operation and records the log.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a program for a namespace-based system access control method, the program implementing the namespace-based system access control method as described in any one of claims 1 to 7.

Images