A lightweight security protection method for file permission access in a localization scenario

Abstract

The application discloses a lightweight security protection method for file permission access in a localization scenario, and belongs to the technical field of information security and localization system security. The application effectively delays the attack process and blocks the automated attack through three technical aspects, including file access interception and underlying permission control, virtual Shell hiding and induction, and external command hiding and path migration. At the same time, a set of user-oriented file permission access and Shell acquisition approval system is formulated, forming a file permission access management and control mechanism, and empowering the localization system security. The lightweight security protection method breaks through the limitations of traditional methods, embeds security strategies into the file system and command path, and is suitable for localization systems in specific scenarios. Under the premise of ensuring the availability of normal users and operation and maintenance processes, the application can effectively delay the execution of attack chains, prevent automated attacks and enhance system security.

Description

Technical Field

[0001] This invention belongs to the field of information security and domestic system security technology, and relates to system protection and access control, and the security of domestic operating systems. Specifically, it relates to a lightweight security protection method for file permission access in domestic scenarios. Background Technology

[0002] As file access attack methods continue to evolve, attackers typically obtain a WebShell (where "Web" refers to the server needing to provide a web service, and "Shell" refers to the privilege to execute commands on the server) through file upload vulnerabilities and code injection vulnerabilities. They then execute commands on the server as a regular user and exploit sudo misconfigurations, SUID (Set UserID) programs, and kernel vulnerabilities to escalate privileges and ultimately gain root access. For domestically developed and controllable applications, where access control is not strict, attackers are more vulnerable to breaches.

[0003] These attack processes share a common assumption: the operating system environment is consistent with publicly available documentation, namely: common command paths are fixed (e.g., / bin, / ls, / usr, / bin, / vim); file permission inheritance rules conform to default behavior (e.g., umask); file systems and system calls follow standard documentation; and privilege escalation tools and scripts can directly reuse publicly available schemes. Therefore, attack scripts based on the above "consensus" are usually automated and efficient.

[0004] Existing research and practice regarding this attack process mainly focus on the following aspects:

[0005] 1. Border defense:

[0006] (1) Strict input validation prevents common vulnerabilities such as SQL (Structured Query Language) injection, command injection, XSS (Cross Site Scripting), and template injection.

[0007] (2) Restrict file uploads by using whitelists to limit the types of files that can be uploaded, MIME (Multipurpose Internet Mail Extensions) checks, magic byte verification, and prohibiting the upload of executable scripts such as JSP (JavaServer Pages), PHP (Hypertext Preprocessor), and ASP (Active Server Pages).

[0008] 2. Reduce the risk of privilege escalation by restricting user permissions. Common measures include:

[0009] (1) The principle of least privilege. For example, prohibit web services (such as tomcat / nginx / php-fpm) from running as root, and assign web users the minimum file access permissions (prohibit reading and writing / etc / shadow, prohibit writing to system directories). In this case, once an attacker gains shell access by exploiting vulnerabilities such as file uploads, it is difficult to obtain further privilege escalation.

[0010] (2) File system isolation. By using chroot or containers (such as Docker / K8s), web applications can be isolated to avoid direct access to the host machine.

[0011] 3. Patching and baseline reinforcement:

[0012] While updates and hardening reduce the vulnerability surface, the time lag between vulnerability disclosure and remediation still leaves opportunities for attackers. Common baseline hardening measures include disabling or deleting default accounts (such as root / administrator as the default remote login), enforcing complex password policies (length, complexity, and expiration time), and disabling or uninstalling unnecessary services / features (such as FTP, Telnet, and rsh).

[0013] 4. Honeypots and Deception Defense:

[0014] By deploying decoy resources (fake WebShells, fake configuration files, etc.), attackers are misled during the post-penetration information gathering process. However, these resources often exist as additional resources and are easily identified by experienced attackers.

[0015] These defense methods share a common thread: the defender operates under the assumption of a "standardized operating system and tool environment." However, attackers precisely base their automated exploitation tools and privilege escalation scripts on this assumption (e.g., fixed command paths and behaviors for ls, vim, and bash, and sudo rules conforming to general logic). Once attackers can reuse existing knowledge, their attack chains often execute with extremely high efficiency.

[0016] Existing security defenses are often well-known to attackers, who can bypass them based on known conditions, such as encryption, obfuscation, and traffic spoofing bypasses of perimeter defenses. Furthermore, because existing defenses are typically based on external security software, they are difficult to apply to lightweight devices (such as water meters and valves). Therefore, a lightweight, configurable security hardening strategy is urgently needed. Summary of the Invention

[0017] To compensate for the shortcomings of existing defense methods, this invention provides a lightweight security protection method for file permission access in domestic scenarios. By actively breaking attackers' standard assumptions about the system environment, creating unpredictability and information gaps, it delays the attack process and creates a detection window.

[0018] To achieve the above objectives, the present invention adopts the following technical solution:

[0019] In a first aspect, the present invention provides a lightweight security protection method for file permission access in a domestically produced scenario, comprising:

[0020] Add security judgment logic to the underlying functions of the file system. When a user creates a new file, forcibly revoke the read and execute permissions of the new file, restrict the types of files that can be created according to the filtering policy, and record security logs. The filtering policy includes whitelist policy and blacklist policy.

[0021] For user access to new files, a one-time file permission token is generated through a file permission approval process. The user's file access permissions are dynamically upgraded based on the one-time file permission token, and the validity period of the file access permissions is set. After the expiration, the file access permissions are automatically downgraded.

[0022] Virtualize WebShell requests and redirect them to a controlled Fake-Shell service to simulate command interactions and block sensitive operations, while recording all interactions.

[0023] By hiding or migrating external commands to the system and allowing only authorized users to access them, an information gap can be created within the system to delay the attack process.

[0024] In a second aspect, the present invention provides an electronic device comprising: one or more processors; a memory for storing one or more programs; wherein, when the one or more programs are executed by the one or more processors, the one or more processors implement the aforementioned method.

[0025] Thirdly, the present invention provides a computer-readable storage medium having executable instructions stored thereon, which, when executed by a processor, enable the processor to implement the aforementioned method.

[0026] The beneficial effects of this invention are as follows:

[0027] The lightweight security protection method of this invention breaks through the limitations of traditional methods by embedding security policies into the file system and command path. It is suitable for domestically produced systems in specific scenarios and can effectively delay the execution of attack chains, prevent automated attacks, and enhance system security while ensuring the availability of normal users and operation and maintenance processes. Attached Figure Description

[0028] Figure 1 This is a flowchart illustrating the lightweight security protection method for file permission access in the context of domestic application of the present invention.

[0029] Figure 2 This diagram illustrates a defense strategy for file access attacks using the method of the present invention.

[0030] Figure 3 This is a flowchart illustrating how to obtain a Shell based on file access using the method of the present invention. Detailed Implementation

[0031] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0032] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0033] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0034] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0035] Furthermore, to better illustrate the present invention, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that the present invention can be practiced without certain specific details. In some instances, methods, means, elements, and circuits well known to those skilled in the art have not been described in detail in order to highlight the spirit of the invention.

[0036] Under resource-constrained conditions such as limited installation space and inadequate security facilities, system defenses primarily rely on standard operating system configurations, characterized by fixed command execution paths and non-standard execution processes. Attackers can obtain WebShells through file upload vulnerabilities and exploit sudo misconfigurations, SUID programs, or kernel vulnerabilities to escalate privileges, forming highly efficient automated attack chains. To address the shortcomings of existing defenses, this invention provides a lightweight security protection method for file permission access in domestically developed scenarios.

[0037] Figure 1 The flowchart illustrates a lightweight security protection method for file permission access in a domestically developed scenario, as described in the present invention. Figure 1 As shown, the method includes:

[0038] Add security judgment logic to the underlying functions of the file system. When a user creates a new file, forcibly revoke the read and execute permissions of the new file, restrict the types of files that can be created according to the filtering policy, and record security logs. The filtering policy includes whitelist policy and blacklist policy.

[0039] For user access to new files, a one-time file permission token is generated through a file permission approval process. The user's file access permissions are dynamically upgraded based on the one-time file permission token, and the validity period of the file access permissions is set. After the expiration, the file access permissions are automatically downgraded.

[0040] Virtualize WebShell requests and redirect them to a controlled Fake-Shell service to simulate command interactions and block sensitive operations, while recording all interactions.

[0041] By hiding or migrating external commands to the system and allowing only authorized users to access them, an information gap can be created within the system to delay the attack process.

[0042] It should be noted that, in this invention, "new file" refers to a file newly created or uploaded after applying the method of this invention, while "old file" refers to a file that existed before applying the method of this invention.

[0043] For example, the file system can be a littlefs file system or other lightweight file systems.

[0044] For example, a whitelist policy may include allowing only specific users to create executable files in specific directories.

[0045] For example, blacklist policies include prohibiting the uploading of executable scripts, such as Shell scripts (.shell), PHP scripts (.php), and JSP scripts (.jsp).

[0046] For example, security logs are used to record and alert on each unauthorized creation of a new file.

[0047] For example, the file permission approval process includes:

[0048] (1) The user submits a work order; the work order is used to request access to the target file; the access to the target file includes read permission and / or execute permission;

[0049] (2) The approver approves whether to approve the user's application;

[0050] (3) If the approver approves the user’s application, the approval system generates the one-time file permission token for the user.

[0051] For example, the method further includes: for a user's operation of obtaining a Shell based on file access, generating a one-time Shell access token through a Shell authorization approval process, and dynamically adjusting the user's Shell access permissions based on the one-time Shell access token.

[0052] like Figure 1 As shown, the approval system includes an authorization approval module and a Shell approval module. The authorization approval module is used to generate one-time file permission tokens, and the Shell approval module is used to generate one-time Shell access tokens.

[0053] For example, the Fake-Shell service is used to return virtual results for common commands and block sensitive operations; the sensitive operations include the sudo command and the su command.

[0054] For example, hiding or migrating external commands to the system includes:

[0055] The sensitive command is moved from the default storage directory to a non-default storage directory (i.e., a directory not in the system's default PATH search path), and a pseudo-command with the same name as the sensitive command is generated in the default storage directory. This pseudo-command is used to block unauthorized users from executing the real sensitive command. Alternatively, a controlled executable file with the same name as the sensitive command is deployed in a high-priority position in the PATH (the directory searched first in the operating system's search path when the user enters the relative path of the command, i.e., a high-priority directory in the PATH). This allows the controlled executable file to be triggered when an unauthorized user enters the sensitive command through a relative path, while the real sensitive command can only be executed through a specified absolute path. The sensitive command includes external system commands commonly used by attackers.

[0056] This invention effectively delays attack processes and blocks automated attacks through three technologies: file access interception and low-level permission control, virtual shell hiding and manipulation, and external command hiding and path migration. Simultaneously, it establishes a user-oriented file permission access and shell acquisition approval system, forming a file permission access control mechanism that empowers the security of domestically developed file systems. The three technologies of this invention are described in detail below.

[0057] I. File Access Interception and Underlying Permission Control:

[0058] To prevent attackers from gaining shell access through file upload functionality, the primary defense is to restrict permissions on newly created files, while leaving uploads unrestricted. Traditional methods for restricting file permissions include the following three:

[0059] (1) Modify the umask value:

[0060] `umask` is a mask used in Linux to control the default permissions of newly created files / directories. The permissions of a newly created file / directory are equal to the default permissions and (~umask). By adjusting the `umask` value, the default permissions for creating new files can be restricted (e.g., removing write or execute permissions). However, since this method is a standard function provided by the operating system and is a common configuration, attackers with the appropriate permissions can also bypass this restriction by modifying the `umask` value. Therefore, this method has limited defensive effectiveness.

[0061] (2) Use ACL (Access Control List) to restrict permissions:

[0062] ACLs allow setting independent permissions for specific users or groups. Permissions for newly created files in a specified directory can be changed by setting a default ACL. However, ACLs require additional configuration and maintenance, are complex, and are prone to configuration errors. Furthermore, as an "additional mechanism" at the operating system level, ACLs cannot prevent direct exploitation of the underlying file system.

[0063] (3) Combining SUID / SGID (Set Group ID) restrictions (for directory inheritance):

[0064] If a directory has an SGID set, newly created files will inherit the parent directory group. Combined with umask or default ACLs, this ensures that file permissions and group inheritance comply with the policy. However, this method relies on the directory structure and inheritance rules, lacking flexibility. Attackers can still circumvent this restriction by bypassing directory constraints or abusing inheritance rules.

[0065] In summary, traditional methods for restricting file permissions rely on built-in operating system functions, which are standard configurations that can be modified by anyone, including attackers. Therefore, this invention directly intervenes at the file system code level, proposing a method based on enhancing underlying file system functions to restrict permissions for newly created files. This method does not rely on configuration options exposed by the operating system but directly modifies the underlying file system code logic.

[0066] like Figure 1As shown, the LittleFS file system, commonly used in embedded systems / lightweight devices, is used as an example for illustration. The file operation functions of the LittleFS file system (including lfs_file_open(), lfs_dir_commit(), etc.) are the foundation of all upper-level calls; these functions are also known as the low-level functions of the file system. This invention restricts the permissions of newly created files by users by adding security judgment logic to the logic of these low-level file system functions. The security judgment logic may include:

[0067] (1) Whitelist policy: Only allow specific users to create executable files in specific directories;

[0068] (2) Blacklist policy: Prohibit the uploading of executable scripts (e.g., .sh, .php, .jsp);

[0069] (3) Forced permission downgrade: When a new file is created, the read and execute permissions of the new file are forcibly revoked;

[0070] (4) Security Log Recording: Record and alert for each unauthorized creation of new files.

[0071] For all new files (newly created or uploaded files), the file system prevents dangerous files from entering the "executable" state at the lowest level. Even if the upload is successful, the files cannot be executed, completely blocking the attack chain. This invention adds security judgment logic to the underlying functions of the file system, blocking the exploitation path of malicious files at the source. This overcomes the limitations of traditional security protection that relies on system configuration, making it particularly suitable for IoT (Internet of Things), embedded, and lightweight systems, and enabling mandatory security policies with low overhead.

[0072] For user update operations or other file upload requests within the system, this invention designs an internal process to create information asymmetry. By default, uploaded files are unreadable and non-executable; access permissions can only be elevated after verification and approval, and any permission changes must be accompanied by an approval ID and audit log. The detailed process design is as follows:

[0073] (1) Users upload new files and submit a request work order in the intranet work order system according to their needs. The approval process is carried out. The work order specifies the file to be authorized (i.e. the target file) and the required permissions (read permission or read permission + execute permission).

[0074] (2) After the approver agrees, the authorization approval module in the approval system generates a one-time file permission token, which is bound to the hash of the target file and the requester's device (i.e. the user's device).

[0075] (3) The background service uses administrator privileges to elevate the permissions of the target file based on the one-time file permission token, and sets the validity period of the permissions. After the expiration, the system will automatically downgrade the permissions.

[0076] II. Virtual Shell Hiding and Manipulation:

[0077] For existing old files (including Trojans or viruses), by hiding the shell file, a fake shell is returned when the old file is executed, thus prolonging the attack time. This invention directs all WebShell requests to a controlled "virtual shell service," which simulates interaction but blocks important commands, allowing only safe commands, and records the entire process.

[0078] This invention deploys a Fake-Shell backend (an independent process) alongside a web server, forwarding WebShell requests to the Fake-Shell service via a gateway proxy. The Fake-Shell service returns plausible output for common commands but does not actually execute system commands; for example, when executing the `ls` command, the shell returns "fake data" of directory listings. Furthermore, the Fake-Shell service can whitelist requests for uploading / reading sensitive files (returning only simulated data) and record all interactions for fingerprint extraction and tracing.

[0079] For WebShell requests from normal users (such as operations and maintenance personnel), this invention designs an internal process to build information asymmetry. This invention establishes dedicated operations and maintenance accounts for operations and maintenance personnel, and pre-configures an approval mechanism for authorization. The approval process is as follows:

[0080] (1) The maintenance personnel initiate a request work order for “accessing host X to obtain a shell” in the intranet work order system, and explain the reason, duration and scope of impact in the work order.

[0081] (2) After the manager or designated approver agrees, the Shell approval module in the approval system generates a one-time Shell access token, which is bound to the ID of the request work order and the requester's device (i.e. the device of the maintenance personnel).

[0082] (3) When the operation and maintenance personnel submit a one-time Shell access token, the system calls the approval service to verify the work order and approval status. If the verification is successful, the system creates a Shell for the operation and maintenance personnel and restricts their capabilities (such as not allowing the execution of su / sudo commands by default). If the sudo command needs to be executed within this session, a second approval is required.

[0083] III. External Command Hiding and Path Migration:

[0084] For certain permissions required by users, this invention mainly changes the original standards by modifying the command path, thereby creating an information gap.

[0085] For ordinary users, commands in the Linux operating system can be mainly divided into two categories:

[0086] (1) Shell built-in commands, which are directly interpreted and executed by the shell (such as bash, zsh) without relying on external binary files, such as cd, pwd, echo, history, type, exit, etc. This invention does not restrict these commands.

[0087] (2) External commands are actually executable binary files in the file system (usually located in directories such as / bin, / usr / bin, / usr / local / bin), such as / bin / ls, / bin / cat, / bin / mkdir, / usr / bin / vim, / usr / bin / python3, and / usr / bin / grep. These commands require a fork / exec process to be executed, and the kernel loads the binary. Whether a regular user can execute them depends on the permissions of these binary files (whether the executable bit x is open to that user). This invention primarily targets and restricts such commands.

[0088] When a user enters a command (such as ls or . / script.sh) in the shell, the system recognizes the following steps:

[0089] (1) Check if it is a built-in command. Shell first determines whether the entered command belongs to its built-in function. For example, if you enter cd, Shell will directly call the built-in function instead of going to / bin / cd.

[0090] (2) Check if the path separator " / " is present. If the user enters . / a.out or / usr / bin / python3, the shell will assume that the user has specified a path and will execute the program directly at that specified path without searching further.

[0091] (3) Searching for external commands according to the PATH environment variable. If the command is not a built-in command and does not contain the path separator " / ", the shell will search through the directories specified in the PATH environment variable one by one. For example: $PATH: / usr / local / sbin; / usr / local / bin; / usr / sbin; / usr / bin; / sbin; / bin. When you type ls, the shell will search for the ls executable file in these directories in turn, and execute the first one it finds. That is to say, the ls command is actually / bin / ls, but PATH makes it so that the user does not have to write the absolute path.

[0092] (4) Loading and execution. After finding the executable file, the Shell uses fork()+execve() to load and run the program. After the program finishes running, control returns to the Shell.

[0093] The commands that this invention focuses on include the following three categories:

[0094] (1) Commonly used commands for attackers to escalate privileges: sudo, vim, less, find, perl, python.

[0095] (2) Commonly used commands for attackers to collect information: id, whoami, uname, ifconfig, netstat, ps, ls, cat.

[0096] (3) Commonly used commands for attackers to download Trojans / scripts: wget, curl (used to download Trojans / scripts).

[0097] This invention migrates and replaces the paths of commonly used external commands (such as / bin / ls, / usr / bin / vim, / usr / bin / python3, etc.) by ordinary users (users who have not been approved or authorized and are not attackers), exposing only the controlled set of commands. This method adjusts the actual storage path and search path of executable commands to create system information gaps and restrict unauthorized users from executing system commands, specifically including any of the following methods:

[0098] (1) Command path migration and pseudo-command replacement methods:

[0099] The original binary commands of the system are moved from the default system directory (such as / bin) to a non-default directory (such as / usr, / bin), and a pseudo binary file (i.e. a pseudo command) with the same name that has limited functions or no actual execution logic is created in the original location. This allows unauthorized users to execute only the controlled pseudo command when they call the command, thereby blocking the execution of real system commands.

[0100] (2) Constructing hidden layers using PATH priority:

[0101] Without changing the original command path of the system, a controlled executable file with the same name is placed at the top of the priority search path in the system PATH (such as / opt / restricted / ). This ensures that when an attacker enters a command through a relative path, only the controlled executable file will be triggered. The real command can only be executed when an absolute path is explicitly specified, thereby achieving hierarchical management of permissions for the actions of normal users and attackers.

[0102] In one embodiment of this invention, a separate account can be assigned to applications providing external services (especially for self-controlled applications) on a lightweight device (e.g., the littlefs file system), and the account permissions should be configured to adhere to the principle of least privilege as much as possible. New files created by this account require read and execute permissions through an internal file permission approval process. All requests to initiate a shell using a file require the account to go through an internal shell authorization approval process. If the account accesses a file or requests a shell in the default manner, an alert event will be triggered. This invention extends attack time and prevents automated attacks by creating information gaps through file system-level modifications and hiding operating system commands.

[0103] This invention provides a method for batch configuring accounts: Account configuration requires system administrator privileges. First, a user is created. Then, based on the needs of the service program, permissions are assigned to the user while maximizing compliance with the principle of least privilege. Finally, the paths for external commands that the user can execute are migrated. This process can be automated into a script, thus enabling batch account configuration.

[0104] The following description, in conjunction with the accompanying drawings and embodiments, provides an exemplary account of how to defend against file access attacks using the method of the present invention, and how to obtain a shell based on file access using the method of the present invention.

[0105] Figure 2 This diagram illustrates a defense strategy for strengthening against file access attacks using the method of the present invention. Figure 2 As shown, a file access attack includes the following brief steps: information gathering, file upload, obtaining a WebShell, information verification (verifying Shell permissions, identity, etc.), privilege escalation, obtaining and persisting root privileges, and lateral movement. This invention prevents attackers from obtaining a WebShell by intercepting file access and hiding the Shell, and prevents attackers from executing sensitive commands by hiding OS (Operating System) level command paths, thus preventing attackers from achieving information verification and privilege escalation.

[0106] Figure 3This is a flowchart illustrating how to obtain a shell based on file access using the method of this invention. For example... Figure 3 As shown, if a user wants to obtain a shell by executing a file, the process includes a file access phase and a shell acquisition phase.

[0107] During the file access phase, the system first checks whether the file the user wants to execute is a new file. If it is not a new file, it can be executed successfully. If it is a new file, the user needs to submit a work order to obtain file execution permissions. This work order is forwarded to the superior for approval. If the superior does not approve the application, the process returns to the user submitting the work order. If the superior approves the application, the approval system generates a one-time file permission token for the user. The user submits the one-time file permission token to request the execution of the file. The system checks whether the token matches the hash of the file and the requesting device (i.e., the user's device). If they match, the file is executed successfully; if they do not match, the file execution fails.

[0108] During the Shell acquisition phase, the system first checks whether the user has Shell access permissions. If so, the system returns a Shell. If the user does not have Shell access permissions, the user needs to submit a work order to obtain Shell access permissions. This application is forwarded to the superior for approval. If the superior does not approve the application, the process returns to the user submitting the application. If the superior approves the application, the approval system generates a one-time Shell access token for the user. The user submits the one-time Shell access token to request Shell access. The system checks whether the token matches the request ID (i.e., the work order ID) and the requesting device. If they match, the system returns a Shell. If they do not match, the system refuses to return a Shell.

[0109] The present invention also provides an electronic device, comprising: one or more processors; a memory for storing one or more programs; wherein, when one or more programs are executed by the one or more processors, the one or more processors implement the aforementioned lightweight security protection method for file permission access in the context of domestic production.

[0110] The present invention also provides a computer-readable storage medium storing executable instructions thereon, which, when executed by a processor, enable the processor to implement the aforementioned lightweight security protection method for file permission access in the domestic production scenario.

[0111] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code. The solutions in the embodiments of the present invention can be implemented using various computer languages, such as the object-oriented programming language Java and the interpreted scripting language JavaScript.

[0112] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0113] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0114] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0115] The contents not described in detail in this specification are existing technologies known to those skilled in the art.

[0116] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. The above descriptions are exemplary and not exhaustive. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A lightweight security protection method for file permission access in a domestically developed scenario, characterized in that, include: Add security judgment logic to the underlying functions of the file system. When a user creates a new file, forcibly revoke the read and execute permissions of the new file, restrict the types of files that can be created according to the filtering policy, and record security logs. The filtering policy includes whitelist policy and blacklist policy. For user access to new files, a one-time file permission token is generated through a file permission approval process. The user's file access permissions are dynamically upgraded based on the one-time file permission token, and the validity period of the file access permissions is set. After the expiration, the file access permissions are automatically downgraded. Virtualize WebShell requests and redirect them to a controlled Fake-Shell service to simulate command interactions and block sensitive operations, while recording all interactions. Hide or reroute external commands to the system, allowing only authorized users to access them, in order to create information gaps within the system and delay the attack process; The process of hiding or migrating external commands includes: The sensitive command is moved from the default storage directory to a non-default storage directory, and a pseudo command with the same name as the sensitive command is constructed in the default storage directory. The pseudo command is used to block unauthorized users from executing the real sensitive command. Alternatively, a controlled executable file with the same name as the sensitive command can be deployed in a high-priority directory of the PATH. This allows the controlled executable file to be triggered when an unauthorized user enters the sensitive command via a relative path, while the real sensitive command can only be executed via an absolute path. The sensitive command includes external system commands commonly used by attackers.

2. The method according to claim 1, characterized in that, The file system is a lightweight file system; the lightweight file system includes the littlefs file system.

3. The method according to claim 1, characterized in that, The whitelist policy includes allowing only specific users to create executable files in specific directories; The blacklist policy includes prohibiting the uploading of executable scripts; the executable scripts include Shell scripts, PHP scripts, and JSP scripts.

4. The method according to claim 1, characterized in that, The security log is used to record and alert on every unauthorized creation of new files.

5. The method according to claim 1, characterized in that, The file permission approval process includes: The user submits a work order; the work order is used to request access to a target file; the access to the target file includes read permission and / or execute permission. The approver reviews whether to approve the user's application; If the approver approves the user's application, the approval system generates the one-time file permission token for the user.

6. The method according to claim 5, characterized in that, The method further includes: For user operations that obtain Shell based on file access, a one-time Shell access token is generated through a Shell authorization approval process, and the user's Shell access permissions are dynamically adjusted based on the one-time Shell access token.

7. The method according to claim 1, characterized in that, The Fake-Shell service is used to return virtual results for common commands and block sensitive operations; the sensitive operations include the sudo command and the su command.

8. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; Wherein, when one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method of any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, It stores executable instructions that, when executed by a processor, enable the processor to perform the method described in any one of claims 1-7.

Images