User security login method based on eBPF technology and related equipment

Abstract

The invention relates to the technical field of information security, in particular to a user security login method based on an eBPF technology and related equipment. The method comprises the following steps: a control layer edits a user-defined login strategy through a strategy modification tool to obtain strategy configuration containing a version number; when the system is started, an application program tracks system nodes by loading an eBPF program to obtain an audit log; the observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses and user names; the judgment layer carries out login information and strategy matching through an authentication function return node and a user switching hook function in a pluggable authentication module scene to obtain a rejection or permission mark; and the process loading hook function of the security module framework is combined with the mark of the data layer to execute an interception or release instruction. According to the method, the coverage range can be expanded, the forcing force is stronger, and the security, flexibility and efficiency of access control are integrally improved.

Description

Technical Field

[0001] This application relates to the field of information security technology, and in particular to a method and related equipment for secure user login based on eBPF technology. Background Technology

[0002] In Linux systems, the user login process encompasses stages such as network connection establishment, user authentication, user switching, and session initiation. Login programs using the PAM framework iterate through the configured authentication modules to complete authentication. During this process, the PAM framework retrieves the username by calling `pam_get_user` and executes authentication by calling `pam_sm_authenticate` in each module. After successful authentication, the login program calls `setuid` to switch to the target user and then uses `execve` to start the shell or session program.

[0003] The pam_access.so module of PAM can implement login restrictions based on username and the host from which the access originates. It determines whether a user is allowed to log in from a specified terminal or host by parsing the rules defined in / etc / security / access.conf. The configuration is intuitive and allows administrators to quickly formulate access rules. However, this module has significant shortcomings: First, its coverage is limited, and it becomes ineffective when sshd is disabled by PAM; second, its enforcement is insufficient, and denial rules at the account stage may be ignored or bypassed by some applications; third, configuration updates are inconvenient, requiring service reloads after modifications and updates are slow; and fourth, its auditing capabilities are weak, with logs scattered and lacking centralized management.

[0004] In summary, the technical problems existing in the relevant technologies need to be improved. Summary of the Invention

[0005] The main objective of this application is to propose a user secure login method and related devices based on eBPF technology, which can improve coverage, enforce stronger measures, make configuration updates more flexible, unify audit logs and ensure good rollback capability, thereby improving the overall security, flexibility and efficiency of access control.

[0006] To achieve the above objectives, one aspect of this application proposes a method for secure user login based on eBPF technology, the method comprising the following steps: The control layer edits the custom login policy using the policy modification tool to obtain the policy configuration containing the version number; When the system starts, the application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, subscribes to the output of the eBPF program, and obtains audit logs. The observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses, and usernames. The decision layer matches login information and policies with the authentication function return node and user switching hook function in the pluggable authentication module scenario, obtains the deny or allow flag, and writes it to the data layer; The security module framework's process loads the hook function and checks the process request after the user switches, and, in conjunction with the data layer's flags, executes an intercept or allow command.

[0007] In some embodiments, the version number is used for subsequent eBPF programs to verify the validity of data, and the policy is synchronized to the structured storage unit of the data layer in real time after modification.

[0008] In some embodiments, the policy initialization performs integrity verification on the encrypted configuration, and after the verification passes, it is parsed and loaded. Standardize the audit logs when subscribing to the output of an eBPF program.

[0009] In some embodiments, the observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses, and usernames, including the following steps: The observation layer listens to the tracking points through the process creation tracking module, obtains the process identification information, and writes the network address of the parent process and the rejection flag into the process mapping table; The observation layer obtains the remote login network address by filtering and listening to the socket receiving function through the network connection tracking module. The observation layer listens for user authentication requests through the user tracking module to obtain the login username. The observation layer performs windowed monitoring through the authentication function of the PAM authentication tracking module to obtain the authentication time, network address, and username.

[0010] In some embodiments, the process creation tracking module identifies the process creation event of the login program, associates the network address and initial rejection flag of the parent process with the process identifier, and writes them into the process mapping table; The process mapping table uses a key-value pair structure, with the process identifier as the key and the associated information as the value; The network connection tracing module filters only the Secure Shell protocol process, parses the result of the Secure Shell protocol process calling the socket receive function, and extracts the remote login network address; After extraction, the network address is associated with and updated with the corresponding process identifier in the process mapping table, and abnormal network addresses are pre-marked.

[0011] In some embodiments, for pluggable authentication module scenarios, the user tracking module opens a monitoring window when the authentication function is called to record the authentication start time; During the return phase of the function that retrieves the username, the logged-in username is captured and associated with the monitoring window context of the corresponding process; When the authentication function returns, close the window, integrate the authentication time, network address, and username in the window into structured login information, and synchronize it to the temporary storage unit of the data layer.

[0012] In some embodiments, the determination layer matches login information and policies using the authentication function return node and user switching hook function in a pluggable authentication module scenario, obtains a deny or allow flag, and writes it to the data layer, including the following steps: The decision layer first reads the default strategy type stored in the data layer to determine the corresponding matching logic; For pluggable authentication module scenarios, the determination operation is triggered at the authentication function return node, and the structured login information under the pluggable authentication module scenario is directly read for matching; For non-pluggable authentication module scenarios, the determination operation is triggered by the user switching hook function, which reads the login information temporarily stored in the data layer for matching; Once the matching is complete, the generated reject or allow flag will be written to both the state storage unit and the audit log unit of the data layer.

[0013] In some embodiments, the hook function is triggered when the process of the security module framework loads the hook function, either upon completion of a user switching operation or when a process loading request is initiated. Read the deny or allow flag of the corresponding process from the data layer state storage unit; If the rejection flag is set, the process loading request will be blocked directly and an error message will be returned. At the same time, the interception details will be recorded in the audit log. If the flag is set to allow, the request is permitted and the running status of the process is updated to the data layer; The triggering logic of the hook function covers all process loading scenarios after user switching.

[0014] To achieve the above objectives, another aspect of this application proposes a user secure login system based on eBPF technology, the system comprising: The control layer module is used by the control layer to edit custom login policies through a policy modification tool, resulting in policy configurations with version numbers. The audit log module is used when the system starts up. The application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, and subscribes to the output of the eBPF program to obtain the audit log. The observation layer module is used by the observation layer to monitor key nodes through multiple modules and collect process identifiers, network addresses, and usernames. The decision layer module is used by the decision layer to match login information and policies with the authentication function return node and user switching hook function in the scenario of pluggable authentication module, obtain the deny or allow flag and write it to the data layer; The execution module is used by the security module framework's process to load the hook function and check the process request after the user switches, and in conjunction with the data layer's flags, execute intercept or allow instructions.

[0015] To achieve the above objectives, another aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described above.

[0016] The embodiments of this application include at least the following beneficial effects: This application provides a method and related devices for secure user login based on eBPF technology. This solution realizes flexible editing and encrypted storage of login policies through the policy tools of the control layer. Combined with version identification and real-time synchronization mechanisms, it not only ensures policy security but also avoids the need for service restarts to take effect. During the system startup phase, through the full-link tracing of eBPF programs and standardized log subscription, it realizes comprehensive monitoring of the login process and unified management of audit logs. The observation layer collects information such as process identifiers, network addresses, and usernames through multi-module collaboration and completes accurate association, solving the problem of information dispersion and confusion in traditional solutions and providing full-dimensional data support for the judgment stage. The judgment layer triggers judgments for pluggable authentication module scenarios and non-pluggable authentication module scenarios respectively. Combined with the accurate matching of blacklist and whitelist rules, it realizes policy verification covering all login scenarios. At the same time, the tag synchronization mechanism ensures the consistency of subsequent operations. Finally, relying on the process loading hook function of the security module framework, it completes forced interception at the kernel layer, which not only covers all process loading scenarios after user switching but also avoids the risk of application layer bypass. The overall solution effectively addresses the problems of traditional login control, such as narrow coverage, weak enforcement, slow configuration updates, and insufficient auditing capabilities, achieving more efficient and secure user login management. Attached Figure Description

[0017] Figure 1 This is a flowchart of a user secure login method based on eBPF technology provided in an embodiment of this application; Figure 2 This is a schematic diagram of a hierarchical collaboration structure; Figure 3 This is a flowchart illustrating the user's secure login initialization process; Figure 4 This is a sequence diagram of hierarchical collaboration; Figure 5 This is a flowchart illustrating the policy modification tools provided by the control layer; Figure 6This is a schematic diagram of the mark update process in the decision layer implementation; Figure 7 This is a schematic diagram of the decision-making process at the decision layer; Figure 8 This is a flowchart illustrating the interception mechanism in the interception layer implementation; Figure 9 This is a schematic diagram of the structure of a user secure login system based on eBPF technology provided in an embodiment of this application; Figure 10 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0018] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of this application and are not intended to limit it. In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those of this application; they are merely examples of apparatuses and methods consistent with some aspects of the embodiments of this application as detailed in the appended claims.

[0019] It is understood that the terms “first,” “second,” etc., used in this application may be used herein to describe various concepts, but unless otherwise stated, these concepts are not limited by these terms. These terms are only used to distinguish one concept from another. For example, without departing from the scope of the embodiments of this application, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the words “if,” “when,” or “in response to a determination” as used herein may be interpreted as “when…” or “when…” or “in response to a determination.”

[0020] As used in this application, the terms "at least one", "multiple", "each", "any", etc., "at least one" includes one, two or more, "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the multiples.

[0021] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit the scope of this application.

[0022] Before providing a detailed description of the embodiments of this application, some of the nouns and terms involved in the embodiments of this application will be explained first. The nouns and terms involved in the embodiments of this application are subject to the following interpretations.

[0023] eBPF programs are dynamic programs that run in the Linux kernel. They do not require modification of the kernel source code or a system restart. They can track system calls, process behaviors, and other events, enabling flexible monitoring, judgment, and interception, with execution efficiency close to that of native kernel code.

[0024] PAM, or Plug-in Authentication Module, is an authentication framework for Linux systems. It enables user login authentication by configuring different modules, supports multiple authentication methods such as password and fingerprint, and is compatible with various login programs.

[0025] BPF Mapping Table: The core data structure of an eBPF program. It stores data in kernel mode and supports data interaction between user mode and kernel mode, as well as between different eBPF programs. It can classify and store information such as policy configuration and process status.

[0026] Process ID (PID): A unique numerical identifier assigned to each process by the Linux system to distinguish different processes. It can be used to obtain information such as the parent process and running status of a process.

[0027] sched_process_fork trace point: A trace point provided by the Linux kernel, triggered when a process executes fork to create a child process, and can capture key information such as the parent and child process identifiers and creation time.

[0028] The fork system call is the core system call in Linux for creating new processes. It generates new processes (child processes) by copying existing processes (parent processes) and is the basic method for process creation.

[0029] Sshd: The Secure Shell protocol daemon listens for remote login requests, handles user network connections and authentication, and is the core service for Linux remote login.

[0030] The sys_exit_accept4 function is a kernel function that handles socket connections. It is triggered when processes such as sshd complete the remote connection reception and can capture network information such as the IP address of remote logins.

[0031] The input_userauth_request operation is a key operation in the sshd process for handling user authentication requests. During this stage, authentication information such as the login username submitted by the user can be obtained.

[0032] pam_unix.so: pam_sm_authenticate: This is a Unix authentication module function in the PAM framework, responsible for verifying whether the user's account and password match. It is the core step of PAM authentication.

[0033] tgid_ip_map: A storage structure built on the BPF mapping table, used to associate process identifiers with corresponding IP addresses, rejection flags, and other information to enable cross-module data transfer.

[0034] libpam.so.0:pam_get_user: The core function of the PAM framework, used to extract the login username from the authentication request, providing user identification information for subsequent authentication steps.

[0035] pam_sm_authenticate: The unified authentication interface function of the PAM authentication module. All types of PAM authentication modules need to implement this function to complete the specific authentication logic processing.

[0036] Hook functions: Function interfaces reserved in the kernel or framework that execute custom logic when specific events are triggered. They can be used to intercept and monitor system behavior, such as user switching and process loading.

[0037] Setuid: A Linux system call used to switch the effective user ID of a process to the target user ID. It is a key operation for switching to a regular user after the login program has been authenticated.

[0038] task_fix_setuid: A hook function of the Linux Security Module (LSM) that is triggered when a process executes setuid to switch users. Login policy determination can be performed at this stage.

[0039] bprm_check_security: A hook function of the Linux Security Module (LSM) that is triggered when a process loads an executable program. It is a key node in the kernel layer for intercepting unauthorized login processes.

[0040] eBPF technology: Extended Berkeley Packet Filtering technology, which allows custom programs to run securely within the Linux kernel, enabling real-time tracking, analysis, and control of system behavior. It is widely used in networking, security, and performance analysis.

[0041] In related technologies, system login includes three scenarios: graphical login, local terminal login, and Secure Shell protocol remote login. All three ultimately encompass two core stages: user authentication and session initiation. The authentication stage is mostly completed through a pluggable authentication module framework, while the session stage is implemented through user switching and process initiation. Specifically, local terminal login sequentially executes pluggable authentication module authentication, user switching, and session initiation. Graphical login requires a graphical program to initiate pluggable authentication module authentication, then generates a child process through process creation, subsequently completing user switching and starting the session script. Secure Shell protocol remote login, due to network address association, needs to track process creation events so that the child process inherits the parent process's network address, and subsequently also executes pluggable authentication module authentication, user switching, and session initiation. The differences among the three login scenarios mainly lie in the pre-authentication processes, but ultimately they all converge to a unified authentication-session initiation core link.

[0042] In view of this, this application provides a method and related device for secure user login based on eBPF technology. By tracking the PAM framework and SSHD, it can cover non-PAM authentication scenarios for SSHD; it provides a user-level program that can update policies without restarting any services; and because the interception is performed at the kernel level, the possibility of bypassing is greatly reduced.

[0043] Figure 1 This is an optional flowchart of a user secure login method based on eBPF technology provided in an embodiment of this application. Figure 1 The method may include, but is not limited to, steps S110 to S150.

[0044] In step S110, the control layer edits the custom login policy using the policy modification tool to obtain a policy configuration containing a version number; Step S120: When the system starts, the application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, subscribes to the output of the eBPF program, and obtains audit logs. In step S130, the observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses, and usernames. In step S140, the decision layer matches login information and policies with the authentication function return node and user switching hook function in the pluggable authentication module scenario, obtains a deny or allow flag, and writes it to the data layer. In step S150, the process loading hook function of the security module framework checks the process request after the user switches, and executes the intercept or allow command in combination with the data layer's flag.

[0045] Steps S110 to S150 as illustrated in this embodiment involve the control layer editing a custom login policy using a policy modification tool, generating an encrypted configuration, and loading it into the system. Upon system startup, the application loads the eBPF program to track system nodes, simultaneously reads the encrypted configuration to complete policy initialization, and subscribes to eBPF output to obtain unified audit logs. The observation layer, through multi-module collaboration, monitors processes to create tracking points, obtains process identifiers and writes them to the parent process's network address, adds a rejection flag to the process mapping table, filters listening socket receive functions to obtain the remote login network address, monitors user authentication request operations to obtain the login username, and simultaneously performs windowed monitoring of the pluggable authentication module's authentication function, integrating authentication time, network address, username, and updating the context. The decision layer distinguishes between pluggable authentication module scenarios and non-scenarios, matches login information with the policy, generates a rejection / allow flag, and writes it to the data layer. Finally, through the process loading hook function of the security module framework, it checks process requests after user switching and, combined with data layer flags, performs interception or allow operations to achieve secure login management throughout the entire process.

[0046] like Figure 2 As shown, in step S110, the control layer first writes the administrator-defined login policy into the data layer, completing the encrypted storage and loading of the policy. When a user initiates a login request, the observation layer collects key information such as process identifier, network address, and username during the login process and synchronously writes it into the runtime state storage unit of the data layer. The decision layer reads the policy configuration stored in the data layer and the login information collected by the observation layer, performs a matching decision, generates an allow or deny flag, and then writes the flag back to the data layer. Finally, during the process loading phase after the user switches, the interception layer reads the flag written by the decision layer in the data layer and performs forced interception or allow operations on the login request accordingly. Throughout the process, the data layer, as the core carrier of information interaction, realizes the information flow and state synchronization between the control layer, observation layer, decision layer, and interception layer.

[0047] In some embodiments, in step S120, such as Figure 3As shown, when the login system starts, the corresponding application is automatically launched through preset system services. This application first loads the Extended Berkeley Packet Filter (eBPF) program, completing the mounting of key nodes in the entire login chain, including process creation tracking points, socket receiving functions, pluggable authentication module related functions, user switching hook functions, and process loading hook functions, enabling tracking capabilities for each stage of the subsequent login process. Simultaneously, the application reads the encrypted policy configuration file pre-stored on disk, and through decryption, integrity verification, and version validity verification, parses the configuration into structured policy rules and completes initial loading to make the policy effective. The application subscribes to various event data output during the eBPF program's execution, standardizing and formatting this data. It integrates fields such as login subject, operation node, timestamp, and operation result, ultimately outputting them uniformly to the designated audit log storage path, completing the initialization preparation of the overall solution and providing basic support for the monitoring, judgment, and interception of the subsequent user login process.

[0048] like Figure 4 As shown in the diagram, the collaborative logic of each layer in the user secure login process is illustrated. Specifically, the user first enters their username and password, triggering the pluggable authentication module (PAM module) to perform operations; the observation layer first obtains the login subject information and then synchronizes this information to the data layer; the data layer performs preliminary verification based on the stored policy rules and then passes the information to the decision layer; the decision layer confirms the login information (including username, etc.), performs policy matching and tagging design, and then issues a decision result instruction to the interception layer; the interception layer completes the identification verification and recognition operations based on the decision result, and finally returns the login success or rejection result to the user. At the same time, key information from each layer is synchronized to the data layer for storage and transfer.

[0049] In some embodiments, the data layer is implemented using multiple BPF mapping tables as its core carriers, achieving independent management of different types of data through a categorized storage mechanism. Specifically, the policy configuration mapping table stores encrypted login policy rules and their corresponding version identifiers; the runtime status mapping table records the real-time status of each process in the login process, such as deny / allow flags or information associations; and the temporary information mapping table temporarily stores the login information context collected by the observation layer. Simultaneously, leveraging the version verification feature of the eBPF program, the data layer automatically checks the version identifier stored in the policy configuration mapping table when the observation or decision layer reads configuration data. Only when the version number matches the version of the eBPF program currently loaded by the system will the corresponding policy data be read, avoiding the loading of outdated or incompatible configurations. When the control layer modifies a policy, it synchronously updates the version identifier and encrypted policy content in the policy configuration mapping table, allowing subsequent functional layers to obtain the latest configuration through version verification. Through this design, the data layer achieves structured storage of policy and status data while ensuring the timeliness and compatibility of policy transmission through the version verification mechanism.

[0050] like Figure 5 As shown, the core technology of the control layer lies in providing a policy modification tool that supports real-time policy changes, covering the entire process of policy editing, loading, and storage. Specifically, the policy modification tool allows administrators to initiate policy modification operations via client commands. After the command is passed, the policy rules are first parsed and validated to ensure they conform to a preset format. Once parsing is successful, the tool synchronously writes the rules to the BPF mapping table in the data layer, allowing the new policy to be directly loaded into the running program and take effect immediately without restarting the service. Simultaneously, the tool encrypts the parsed rules and persistently stores the encrypted policy configuration to disk, serving as the initial configuration source for the system's next startup. This is achieved through a linked process of "parsing - real-time writing to the BPF mapping table - encrypted persistence."

[0051] In some embodiments, in step S130, the observation layer is constructed around the collection of information across the entire login process, and achieves multi-dimensional data tracking and correlation through four functional modules. Specifically, the process creation tracking module relies on the Linux kernel sched_process_fork tracking point to capture process creation (fork system call) events and extract the process identifier (PID) information of the parent and child processes; when a fork event of the login program is detected, the remote login IP and initial rejection flag corresponding to the parent process are written into tgid_ip_map (process mapping table) to achieve the binding of IP, rejection flag and process identifier, ensuring the effective transmission of information between system processes. The network connection tracking module: for the sshd process model of "main process listening - accept connection - fork child process processing", it tracks the kernel sys_exit_accept4 function and filters by process name (only matching sshd process) to extract the remote login IP returned by the function, providing data support for locating the login source. The user tracking module focuses on the SSHD authentication process. When SSHD executes the `input_userauth_request` operation (receiving a client login request), it captures and records the username information for this login, completing the initial collection of the login subject's identity. The PAM authentication tracking module, for login programs using the PAM framework, employs a window call mechanism to integrate information. When `pam_unix.so:pam_sm_authenticate` (the PAM password authentication function) is called, a window is opened, recording the authentication start time and reading the associated IP from `tgid_ip_map`. When `libpam.so.0:pam_get_user` (the username retrieval function) returns, the username is captured, and the information in the user tracking module is updated and written to the window context. When `pam_sm_authenticate` returns, the window is closed, integrating the username, IP, and other data within the window into complete login information.

[0052] In some embodiments, in step S140, such as Figure 6 and Figure 7As shown, the core of the decision-making layer relies on the pluggable authentication module framework, user switching system calls, and hook functions of the security module framework to complete policy determination and tag updates, and executes blacklist / whitelist verification logic based on the default policy type. Specifically, the authentication scenarios of the login program are divided into two categories: those using the pluggable authentication module framework and those not using the framework. Not using the framework is a special scenario such as the Secure Shell protocol service. Regardless of the scenario, the login process will trigger a user switching system call to switch to the target user. This system call process will trigger the user switching hook function of the security module framework, which becomes the key linkage node of the decision-making layer. Therefore, the implementation of the decision layer is divided into branch logic corresponding to two authentication scenarios: For scenarios using a pluggable authentication module framework, the decision operation is triggered at the authentication function return node of the pluggable authentication module. At this node, the login information is extracted and the policy judgment is executed. Based on the judgment result, the rejection flag of the corresponding login information in the data layer is directly updated. For scenarios not using a pluggable authentication module framework, the decision operation is triggered at the user switching hook function execution stage of the security module framework. Here, it is first checked whether the login information has been recorded in the data layer and whether there is a rejection flag. If the data layer only records the login information but does not update the rejection flag, the policy judgment is immediately executed and the rejection flag of the corresponding login information is updated.

[0053] The tag update follows a unified process mechanism. Specifically, policy judgment and tag setting are first completed in the pluggable authentication module scenario. If tag setting is not triggered in the pluggable authentication module scenario, policy judgment and tag setting are completed in the user switching hook function of the security module framework. Finally, during the interception phase, the interception judgment is directly executed based on the updated tag. In the specific process of policy judgment, the judgment entry point first reads the system's default policy type (blacklist or whitelist) to determine the verification logic: if the default policy is blacklist, when the login information matches the blacklist rule, a denial tag is set and an audit log containing login information, matching rules, and tagging results is output; if it does not match, an allow tag is set and the corresponding audit log is output. If the default policy is whitelist, when the login information matches the whitelist rule, an allow tag is set and an audit log is output; if it does not match, a denial tag is set and an audit log is output, ensuring that the judgment result of each login is traceable and that the tagging logic strictly corresponds to the default policy.

[0054] In some embodiments, in step S150, as Figure 8As shown, the interception layer is the core component of the login control scheme. The specific process of the interception mechanism is as follows: When a user attempts to log in, PAM authentication is completed first (or this step is skipped). Then, the login process calls `setuid` to switch to the target user. At this time, the system uses the `task_fix_setuid` hook function of the LSM framework to determine the corresponding flag. If a denial flag exists, the login is directly blocked; if no flag exists, the flag is updated first, and then the process of loading the shell or session program begins. During the loading of this program, the `bprm_check_security` hook function of the LSM framework is triggered. Here, the final operation is performed based on the flags pre-set by the decision layer: if an allow flag is detected, the login process is allowed; if a denial flag is detected, the login request is blocked.

[0055] The interception layer uses eBPF technology to perform end-to-end monitoring and tracing of key nodes in the login process, such as PAM authentication, setuid switching, and shell loading. By implementing the interception logic at the kernel level, it covers scenarios where sshd does not use the PAM framework and significantly reduces the risk of application-layer bypass. Furthermore, it uniformly outputs audit logs during interception to support security auditing, and also supports real-time policy updates and global configuration modifications via user-level commands, taking effect immediately without requiring a service restart.

[0056] Please see Figure 9 This application also provides a user secure login system based on eBPF technology, which can implement the above method. The system includes: The control layer module is used by the control layer to edit custom login policies through a policy modification tool, resulting in policy configurations with version numbers. The audit log module is used when the system starts up. The application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, and subscribes to the output of the eBPF program to obtain the audit log. The observation layer module is used by the observation layer to monitor key nodes through multiple modules and collect process identifiers, network addresses, and usernames. The decision layer module is used by the decision layer to match login information and policies with the authentication function return node and user switching hook function in the scenario of pluggable authentication module, obtain the deny or allow flag and write it to the data layer; The execution module is used to load hook functions into the security module framework and check process requests after user switching. Combined with data layer flags, it executes intercept or allow commands.

[0057] It is understood that the content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0058] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the above-described method. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0059] It is understood that the content of the above method embodiments is applicable to this device embodiment. The specific functions implemented by this device embodiment are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0060] Please see Figure 10 , Figure 10 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 101 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 102 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 102 can store the operating system and other applications. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 101 using the methods described above in the embodiments of this application. Input / output interface 103 is used to implement information input and output; The communication interface 104 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, network cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 105 transmits information between various components of the device (e.g., processor 101, memory 102, input / output interface 103, and communication interface 104); The processor 101, memory 102, input / output interface 103 and communication interface 104 are connected to each other within the device via bus 105.

[0061] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0062] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0063] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0064] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0065] It should be understood that the data used in this way can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than those illustrated or described herein. Furthermore, the terms “comprising” and “having”, and any variations thereof, are intended to cover a non-exclusive inclusion, for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such process, method, product, or apparatus.

[0066] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

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

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

[0069] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0070] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method for secure user login based on eBPF technology, characterized in that, The method includes the following steps: The control layer edits the custom login policy using the policy modification tool to obtain the policy configuration containing the version number; When the system starts, the application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, subscribes to the output of the eBPF program, and obtains audit logs. The observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses, and usernames. The decision layer matches login information and policies with the authentication function return node and user switching hook function in the pluggable authentication module scenario, obtains the deny or allow flag, and writes it to the data layer; The security module framework's process loads the hook function and checks the process request after the user switches, and, in conjunction with the data layer's flags, executes an intercept or allow command.

2. The method according to claim 1, characterized in that, The version number is used for subsequent eBPF programs to verify the validity of the data, and the policy will be synchronized to the structured storage unit of the data layer in real time after modification.

3. The method according to claim 1, characterized in that, The strategy initialization performs an integrity check on the encrypted configuration, and after the check passes, it is parsed and loaded. Standardize the audit logs when subscribing to the output of an eBPF program.

4. The method according to claim 1, characterized in that, The observation layer monitors key nodes through multiple modules and collects process identifiers, network addresses, and usernames, including the following steps: The observation layer listens to the tracking points through the process creation tracking module, obtains the process identification information, and writes the network address of the parent process and the rejection flag into the process mapping table; The observation layer obtains the remote login network address by filtering and listening to the socket receiving function through the network connection tracking module. The observation layer listens for user authentication requests through the user tracking module to obtain the login username. The observation layer performs windowed monitoring through the authentication function of the PAM authentication tracking module to obtain the authentication time, network address, and username.

5. The method according to claim 4, characterized in that, The process creation tracking module identifies the process creation event of the login program, associates the network address and initial rejection flag of the parent process with the process identifier, and writes them into the process mapping table; The process mapping table uses a key-value pair structure, with the process identifier as the key and the associated information as the value; The network connection tracing module filters only the Secure Shell protocol process, parses the result of the Secure Shell protocol process calling the socket receive function, and extracts the remote login network address; After extraction, the network address is associated with and updated with the corresponding process identifier in the process mapping table, and abnormal network addresses are pre-marked.

6. The method according to claim 4, characterized in that, For pluggable authentication module scenarios, the user tracking module opens a monitoring window when the authentication function is called to record the authentication start time; During the return phase of the function that retrieves the username, the logged-in username is captured and associated with the monitoring window context of the corresponding process; When the authentication function returns, close the window, integrate the authentication time, network address, and username in the window into structured login information, and synchronize it to the temporary storage unit of the data layer.

7. The method according to claim 1, characterized in that, The determination layer matches login information and policies using the authentication function return node and user switching hook function in the pluggable authentication module scenario, obtains a deny or allow flag, and writes it to the data layer, including the following steps: The decision layer first reads the default strategy type stored in the data layer to determine the corresponding matching logic; For pluggable authentication module scenarios, the determination operation is triggered at the authentication function return node, and the structured login information under the pluggable authentication module scenario is directly read for matching; For non-pluggable authentication module scenarios, the determination operation is triggered by the user switching hook function, which reads the login information temporarily stored in the data layer for matching; Once the matching is complete, the generated reject or allow flag will be written to both the state storage unit and the audit log unit of the data layer.

8. The method according to claim 1, characterized in that, The hook function is triggered when the process of the security module framework loads the hook function, either when the user switching operation is completed or when the process loading request is initiated. Read the deny or allow flag of the corresponding process from the data layer state storage unit; If the rejection flag is set, the process loading request will be blocked directly and an error message will be returned. At the same time, the interception details will be recorded in the audit log. If the flag is set to allow, the request is permitted and the running status of the process is updated to the data layer; The triggering logic of the hook function covers all process loading scenarios after user switching.

9. A user secure login system based on eBPF technology, characterized in that, The system includes: The control layer module is used by the control layer to edit custom login policies through a policy modification tool, resulting in policy configurations with version numbers. The audit log module is used when the system starts up. The application tracks system nodes by loading the eBPF program, completes policy initialization by reading the encrypted configuration, and subscribes to the output of the eBPF program to obtain the audit log. The observation layer module is used by the observation layer to monitor key nodes through multiple modules and collect process identifiers, network addresses, and usernames. The decision layer module is used by the decision layer to match login information and policies with the authentication function return node and user switching hook function in the scenario of pluggable authentication module, obtain the deny or allow flag and write it to the data layer; The execution module is used by the security module framework's process to load the hook function and check the process request after the user switches, and in conjunction with the data layer's flags, execute intercept or allow instructions.

10. An electronic device, characterized in that, The electronic device includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method according to any one of claims 1 to 8.

Images