An access control method and related apparatus

Abstract

The application discloses an access control method, which can be applied to a terminal. The method comprises the following steps: an isolated process intercepts an access request initiated by an untrusted application, and forwards the access request to a host process. The host process executes the access request, and obtains a target descriptor for accessing a system resource, and allocates a proxy descriptor for the target descriptor. Finally, the isolated process forwards the proxy descriptor returned by the host process to the untrusted application, so that the monitoring on the access behavior of the untrusted application is realized.

Description

Technical Field

[0001] This application relates to the field of operating system technology, and in particular to an access control method and related apparatus. Background Technology

[0002] A sandbox is an execution environment that restricts program behavior according to security policies and is now widely used in various operating systems. Taking the Android operating system as an example, some malicious applications request system permissions to obtain user privacy data, perform network access, and other operations, disrupting the normal operation of the system. By deploying applications in a sandbox environment, their behavior can be effectively monitored, thereby protecting system security.

[0003] In related technologies, untrusted applications (hereinafter referred to as untrusted applications) are run in a sandbox and specific access requests initiated by untrusted applications are intercepted to restrict untrusted applications' access to local user data or operating system resources.

[0004] In some cases, untrusted applications running in a sandbox may need to access system resources such as network or local files to provide specific services to the terminal. However, in related technologies, untrusted applications running in a sandbox often have difficulty accessing system resources such as network or local files. Therefore, there is an urgent need for a method that enables untrusted applications in a sandbox to access system resources. Summary of the Invention

[0005] This application provides an access control method and related apparatus. When a first process executes an access request from an untrusted application and obtains a target descriptor pointing to a system resource, the first process allocates a corresponding proxy descriptor for the target descriptor and returns the proxy descriptor to the untrusted application via a second process. In this way, the untrusted application in the second process can obtain the proxy descriptor corresponding to the target descriptor and access the system resource based on the proxy descriptor. Furthermore, when the untrusted application accesses the system resource through the proxy descriptor, it must have the first process replace the proxy descriptor with the target descriptor to complete the access. That is, by avoiding directly returning the target descriptor to the untrusted application, the first process ensures that the behavior of the untrusted application accessing the system resource can be effectively monitored, thus ensuring system security while enabling untrusted application access to system resources.

[0006] The first aspect of this application provides an access control method applied to a terminal, such as a smartphone or tablet running the Android system. A first process and a second process run within the terminal, and the first and second processes can communicate with each other. The first process has permission to access resources on the terminal (e.g., system resources or user personal data), while the second process does not have permission to directly access system resources or only a portion of system resources.

[0007] The access control method specifically includes: a first process receiving a first access request sent by a second process. The first access request originates from a target application running in the second process. For example, the first access request may be for requesting access to system resources in a terminal. The second process does not have permission to execute the access request, while the first process does. The first process executes the first access request to obtain a target descriptor for accessing the system resource. Here, the target descriptor is an abstract concept pointing to a system resource and can be used to identify the system resource. The application can access the corresponding system resource through this target descriptor. After obtaining the target descriptor, the first process assigns a proxy descriptor to the target descriptor. The target descriptor and the proxy descriptor have a corresponding relationship, and the first process can find a unique corresponding target descriptor based on the proxy descriptor. Further, the first process can establish a mapping table that stores the correspondence between target descriptors and proxy descriptors. The first process sends the proxy descriptor to the second process so that the second process returns the proxy descriptor to the target application, and the target application uses the proxy descriptor to access the system resource.

[0008] In this embodiment, when the first process executes an access request from an untrusted application and obtains a target descriptor pointing to a system resource, the first process allocates a corresponding proxy descriptor for the target descriptor and returns the proxy descriptor to the untrusted application via the second process. In this way, the untrusted application in the second process can obtain the proxy descriptor corresponding to the target descriptor and access the system resource based on the proxy descriptor. Furthermore, when the untrusted application accesses the system resource through the proxy descriptor, it must have the first process replace the proxy descriptor with the target descriptor to complete the access. That is, by avoiding directly returning the target descriptor to the untrusted application, the first process ensures that the untrusted application's access to system resources can be effectively monitored, thus ensuring system security while enabling untrusted application access to system resources.

[0009] Furthermore, the solution provided in this embodiment can run the target application in the second process as an Android application package (APK), without needing to obtain the highest privileges of the terminal operating system, without modifying the application framework layer of the operating system, and without modifying the source files of the target application, resulting in high running efficiency.

[0010] In one possible implementation, the first access request may be a system call request, which requests the invocation of an interface provided by the system to access system resources. A system call refers to an interface between an application and the system, such as a program interface or application programming interface (API) provided by the operating system to the application. Applications communicate with the operating system and obtain its services through system calls. In other words, an application can initiate a system call request to request the execution of an interface provided by the operating system, thereby gaining access to system resources.

[0011] In one possible implementation, after the second process returns a proxy descriptor to the target application, the target application can initiate a second access request based on the proxy descriptor. The second access request includes the proxy descriptor to request access to the system resources corresponding to the proxy descriptor. Therefore, the method further includes: the first process receiving a second access request sent by the second process, the second access request including the proxy descriptor, and the second access request being used to request access to system resources. Since the first process establishes a correspondence between proxy descriptors and target descriptors, it can obtain the target descriptor corresponding to the proxy descriptor by looking up the correspondence. This target descriptor is used by the first process to subsequently execute the second access request. The first process executes the second access request based on the target descriptor to obtain a resource access result. The first process then sends the resource access result to the second process.

[0012] In one possible implementation, the first access request is used to initiate network access. The target descriptor obtained by the first process executing the first access request includes a socket descriptor. A socket is the interface through which an application communicates via network protocols. Generally, when an application creates a socket for network communication, the operating system returns a small integer as a descriptor to identify the socket. The application can then use this socket descriptor to reference the socket, thereby enabling network access. In other words, when the first process executes the first access request to initiate network access, the operating system returns a socket descriptor to the first process to identify the socket.

[0013] After the first process returns a proxy descriptor corresponding to the socket descriptor used for network access to the target application, the target application can then initiate a second access request to establish a connection with the target network site. That is, the second access request includes the proxy descriptor and the address of the target network site, and is used to request access to the target network site. Thus, after the first process finds the corresponding socket descriptor based on the proxy descriptor in the second access request, the first process executes the second access request based on the socket descriptor and the address of the target network site, obtaining the access result to the target network site.

[0014] In one possible implementation, when the first access request is used to initiate network access, the first process allocates a proxy descriptor to the target descriptor, including: the first process allocating a channel identifier pair to the target descriptor, the channel identifier pair including a first channel identifier and a second channel identifier, the channel identifier pair being used for data transmission between the first process and the target application, and the socket descriptor having a corresponding relationship with the channel identifier pair. The first process sending the proxy descriptor to the second process specifically includes: the first process sending the first channel identifier to the second process.

[0015] Thus, the second access request initiated by the target application can include the first channel identifier, and the second access request is used to request the establishment of a connection with the target network site. The first process executes the second access request to establish a connection with the target network site. After the first process establishes a connection with the target network site, the data that the target application needs to send to the target network site can be transmitted to the first process based on the data transmission channel corresponding to the first channel identifier, and the first process forwards the data to the target network site based on the corresponding socket descriptor. Similarly, after the target network site returns network data to the first process, the first process returns network data to the target application based on the data transmission channel corresponding to the second channel identifier. Here, the first channel identifier and the second channel identifier correspond to the same data transmission channel; that is, the first process and the target application respectively use two different channel identifiers to achieve data transmission between each other on the same data transmission channel.

[0016] In this embodiment, the first process allocates channel identifier pairs and returns one of the channel identifiers in the pair to the target application, enabling communication between the first process and the target application based on the channel corresponding to the channel identifier pair. This avoids the second process continuously forwarding large amounts of network data exchanged between the first process and the target application, improving data transmission efficiency. Furthermore, the data exchanged between the target application and the network site is transmitted through an independent channel, ensuring the reliability of data transmission.

[0017] In one possible implementation, the first access request initiated by the target application requests to open a target file, and the target descriptor obtained by the first process after executing the first access request includes a target file descriptor. Then, after the target application receives the proxy descriptor returned by the first process, the target application initiates a second access request, and the second access request includes the proxy descriptor, for requesting access to the target file. The first process executes the second access request based on the target descriptor to obtain a resource access result, including: the first process executes the second access request based on the target file descriptor to obtain an access result for the target file.

[0018] In one possible implementation, after the first process allocates a proxy descriptor to the target descriptor, the method further includes: the first process establishing a listener for the proxy descriptor. The first process obtains a message sent by the listener, the message indicating that the proxy descriptor is closed. The first process closes the target descriptor corresponding to the proxy descriptor according to the message. Here, the listener in the system is used to monitor the occurrence of a certain event (program). When the monitored event actually occurs, the event originator (i.e., the event source) sends a message to the listener registered for the event, thereby informing the listener of certain information. Simultaneously, the listener can also obtain an event object, based on which it can obtain relevant attributes and perform related operations, such as the listener sending callback information to the process that registered the listener.

[0019] In this embodiment, the first process can promptly detect the target application's behavior of closing the proxy file descriptor by establishing a listener for the proxy file descriptor, and then promptly close the target descriptor corresponding to the proxy file descriptor, thereby realizing the timely reclamation of system resources.

[0020] In one possible implementation, when the first access request is for network access, the first process establishes a listener for the socket descriptor. The first process receives a message sent by the listener, the message indicating that the socket descriptor is closed. Based on the message, the first process closes the proxy descriptor corresponding to the socket descriptor.

[0021] During the target application's network access, external factors may cause network interruption, preventing the target application from accessing the network. In this case, to promptly reclaim system resources, the first process can monitor the socket descriptor through a listener. If the socket descriptor is closed, it can be considered a network interruption, thus triggering the first process to close the proxy descriptor corresponding to the socket descriptor, thereby promptly reclaiming system resources.

[0022] In one possible implementation, the access request includes information about the target application. The method further includes: the first process performing a permission check on the access request based on the target application information. The purpose of the permission check by the first process is to determine whether the target application in the second process has the permission to request and execute the access request. If the check result indicates that the target application has the access permission, the first process executes the access request and obtains an access result. For example, the access request initiated by the target application includes a system call number and information about the target application. The system call number represents a system call requested by the target application. The information about the target application may, for example, be an identifier of the target application, which identifies the identity information of the target application or identifies the type to which the target application belongs.

[0023] Specifically, the first process can query the access permission information of the applications configured in the terminal based on the system call number and the information of the target application. If the query result shows that the target application has permission to access the system call corresponding to the system call number, then the verification result can be determined that the target application has access permission; if the query result shows that the target application does not have permission to access the system call corresponding to the system call number, then the verification result can be determined that the target application does not have access permission.

[0024] In this embodiment, an untrusted target application is run in a second process that lacks access to the external environment. This second process intercepts access requests initiated by the target application. The second process forwards the intercepted access requests to a first process with access permissions. The first process then verifies the target application's permissions before executing the access request, thereby monitoring the target application's access behavior. Since the second process lacks access permissions by default, the access request is only executed if it is intercepted and the target application has the necessary permissions. This prevents malicious programs running in the second process from gaining access to system resources through anti-interception techniques, ensuring system security.

[0025] In one possible implementation, the second process can create a channel identifier pair based on the access request, the channel identifier pair including a third channel identifier and a fourth channel identifier. Then, the second process adds the third channel identifier to the access request from the target application and sends the access request with the added third channel identifier to the first process. That is, the access request also includes the third channel identifier, which is used to indicate the data transmission channel. The first process sending the access result to the second process includes: the first process sending the access result to the second process through the data transmission channel corresponding to the third channel identifier.

[0026] In this embodiment, when multiple threads are running in the second process, to ensure independent data transmission between the threads, the second process creates an independent data transmission channel for each thread, and each independent data transmission channel is identified by a channel identifier pair. Thus, after the second process intercepts an access request from a thread in the target application, it can include the channel identifier corresponding to that thread in the access request. This allows the first process to return data to the second process from the data transmission channel corresponding to that thread, ensuring data isolation between different threads, effectively preventing data corruption, and guaranteeing the reliability of data transmission.

[0027] In one possible implementation, after the second process creates an independent data transmission channel for the thread, the second process can also add a thread identifier to the access request. This thread identifier is used to identify the thread initiating the access request; that is, the second process adds a thread identifier and a channel identifier to the access request. For example, the first access request and the second access request sent by the second process also include the thread identifier corresponding to the target application. The method further includes: the first process establishing a correspondence between the third channel identifier and the thread identifier based on the first access request; the first process sending the resource access result to the second process, including: the first process determining the third channel identifier based on the thread identifier in the second access request; and the first process sending the resource access result to the second process through the data transmission channel corresponding to the third channel identifier. In other words, when the first process subsequently receives other access requests including the same thread identifier, the first process can determine the corresponding channel identifier based on the thread identifier and send the subsequent access result based on that channel identifier.

[0028] A second aspect of this application provides an access control method, comprising: a second process acquiring an access request from a target application, the target application running in the second process, the second process not having permission to execute the access request; the second process sending the access request to a first process, the first process having permission to execute the access request; the second process receiving a proxy descriptor sent by the first process, the proxy descriptor being used to access system resources; and the second process sending the proxy descriptor to the target application.

[0029] In one possible implementation, the method further includes: the second process acquiring a second access request from the target application, the second access request including the proxy descriptor, the second access request being used to request access to system resources; the second process sending the second access request to the first process; the second process receiving a resource access result sent by the first process; and the second process sending the resource access result to the target application.

[0030] In one possible implementation, the first access request is used to request network access, the second access request further includes the address of the target network site, the second access request is used to request access to the target network site, and the resource access result includes the access result of the target network site.

[0031] In one possible implementation, the proxy descriptor includes a first channel identifier for data transmission between the first process and the target application.

[0032] In one possible implementation, the first access request is used to request opening a target file, the target descriptor includes a target file descriptor, the second access request is used to request access to the target file, and the resource access result includes the access result of the target file.

[0033] In one possible implementation, the method further includes: the second process creating a channel identifier pair according to the access request, the channel identifier pair including a third channel identifier and a fourth channel identifier, the channel identifier pair being used for data transmission between the first process and the second process; the second process adding the third channel identifier to the access request; and the second process sending an access request with the added third channel identifier to the first process.

[0034] In one possible implementation, the method further includes: the second process adding information about the target application to the access request; and the second process sending an access request with the added information about the target application to the first process.

[0035] A third aspect of this application provides a terminal, the terminal including a transceiver unit and a processing unit. The transceiver unit is configured to receive an access request sent by a second process, the access request originating from a target application running in the second process, the second process not having permission to execute the access request; the processing unit is configured to execute the first access request to obtain a target descriptor for accessing system resources; the processing unit is further configured to allocate a proxy descriptor to the target descriptor, the target descriptor and the proxy descriptor having a corresponding relationship; the transceiver unit is further configured to send the proxy descriptor to the second process.

[0036] In one possible implementation, the transceiver unit is further configured to receive a second access request sent by a second process, the second access request including the proxy descriptor, the second access request being used to request access to system resources; the processing unit is further configured to obtain the target descriptor corresponding to the proxy descriptor; the processing unit is further configured to execute the second access request according to the target descriptor to obtain a resource access result; the transceiver unit is further configured to send the resource access result to the second process.

[0037] In one possible implementation, the first access request is used to request network access, the target descriptor includes a socket descriptor, the second access request also includes the address of the target network site, and the second access request is used to request access to the target network site; the processing unit is further used to execute the second access request according to the socket descriptor to obtain the access result of the target network site.

[0038] In one possible implementation, the processing unit is further configured to allocate a channel identifier pair to the target descriptor, the channel identifier pair including a first channel identifier and a second channel identifier, the channel identifier pair being used for data transmission between the first process and the target application, and the socket descriptor having a corresponding relationship with the channel identifier pair; the transceiver unit is further configured to send the first channel identifier to the second process.

[0039] In one possible implementation, the first access request is used to request opening a target file, the target descriptor includes a target file descriptor, and the second access request is used to request access to the target file; the processing unit is further used to execute the second access request according to the target file descriptor to obtain the access result of the target file.

[0040] In one possible implementation, the processing unit is further configured to establish a listener for the proxy descriptor; the transceiver unit is further configured to acquire a message sent by the listener, the message indicating that the proxy descriptor is closed; the processing unit is further configured to close the target descriptor corresponding to the proxy descriptor according to the message.

[0041] In one possible implementation, the processing unit is further configured to establish a listener for the socket descriptor; the transceiver unit is further configured to acquire a message sent by the listener, the message indicating that the socket descriptor is closed; the processing unit is further configured to close the proxy descriptor corresponding to the socket descriptor according to the message.

[0042] In one possible implementation, the access request includes information about the target application; the processing unit is further configured to perform permission verification on the access request based on the information about the target application.

[0043] In one possible implementation, the access request further includes a third channel identifier, which indicates a data transmission channel; the transceiver unit is also used to send the access result to the second process through the data transmission channel corresponding to the third channel identifier.

[0044] In one possible implementation, the first access request and the second access request further include a thread identifier corresponding to the target application; the processing unit is further configured to establish a correspondence between the third channel identifier and the thread identifier based on the first access request; the processing unit is further configured to determine the third channel identifier based on the thread identifier in the second access request; and the transceiver unit is further configured to send the resource access result to the second process through the data transmission channel corresponding to the third channel identifier.

[0045] A fourth aspect of this application provides a terminal, comprising: a transceiver unit and a processing unit. The transceiver unit is configured to acquire an access request from a target application, the target application running in a second process, the second process not having permission to execute the access request; the processing unit is configured to send the access request to a first process, the first process having permission to execute the access request; the transceiver unit is further configured to receive a proxy descriptor sent by the first process, the proxy descriptor being used to access system resources; the transceiver unit is further configured to send the proxy descriptor to the target application.

[0046] In one possible implementation, the transceiver unit is further configured to: acquire a second access request from the target application, the second access request including the proxy descriptor, the second access request being used to request access to system resources; send the second access request to the first process; the second process receiving the resource access result sent by the first process; and the second process sending the resource access result to the target application.

[0047] In one possible implementation, the first access request is used to request network access, the second access request further includes the address of the target network site, the second access request is used to request access to the target network site, and the resource access result includes the access result of the target network site.

[0048] In one possible implementation, the proxy descriptor includes a first channel identifier for data transmission between the first process and the target application.

[0049] In one possible implementation, the first access request is used to request opening a target file, the target descriptor includes a target file descriptor, the second access request is used to request access to the target file, and the resource access result includes the access result of the target file.

[0050] In one possible implementation, the processing unit is further configured to create a channel identifier pair according to the access request, the channel identifier pair including a third channel identifier and a fourth channel identifier, the channel identifier pair being used for data transmission between the first process and the second process; the processing unit is further configured to add the third channel identifier to the access request; the transceiver unit is further configured to send an access request with the added third channel identifier to the first process.

[0051] In one possible implementation, the processing unit is further configured to add information about the target application to the access request; the transceiver unit is further configured to send an access request with the added information about the target application to the first process.

[0052] A fifth aspect of this application provides a terminal comprising: a processor, a non-volatile memory, and a volatile memory; wherein the non-volatile memory or the volatile memory stores computer-readable instructions; and a method by which the processor reads the computer-readable instructions to enable the terminal to implement any one of the implementations of the first aspect or the second aspect.

[0053] The sixth aspect of this application provides a computer-readable storage medium storing a computer program that, when run on a computer, causes the computer to perform a method as implemented in either the first or second aspect.

[0054] The seventh aspect of this application provides a computer program product that, when run on a computer, causes the computer to perform a method as implemented in either the first or second aspect.

[0055] An eighth aspect of this application provides a chip including one or more processors. Part or all of the processors are configured to read and execute a computer program stored in memory to perform the methods in any possible implementation of any of the preceding aspects.

[0056] Optionally, the chip includes a memory, which is connected to the processor via a circuit or wire. Optionally, the chip also includes a communication interface, to which the processor is connected. The communication interface is used to receive data and / or information that needs to be processed. The processor obtains the data and / or information from the communication interface, processes the data and / or information, and outputs the processing result through the communication interface. The communication interface can be an input / output interface. The method provided in this application can be implemented by a single chip or by multiple chips working together. Attached Figure Description

[0057] Figure 1 This is a schematic diagram of the structure of a terminal 101 provided in an embodiment of this application;

[0058] Figure 2 A schematic diagram illustrating an application scenario provided in an embodiment of this application;

[0059] Figure 3 A flowchart illustrating an access control method 300 provided in an embodiment of this application;

[0060] Figure 4 A flowchart illustrating an access control method 400 provided in an embodiment of this application;

[0061] Figure 5a A flowchart illustrating an access control method 500 provided in an embodiment of this application;

[0062] Figure 5b This is another flowchart illustrating an access control method 500 provided in an embodiment of this application;

[0063] Figure 6a A flowchart illustrating an access control method 600 provided in an embodiment of this application;

[0064] Figure 6b This is another flowchart illustrating an access control method 600 provided in an embodiment of this application;

[0065] Figure 7A flowchart illustrating an access control method 700 provided in an embodiment of this application;

[0066] Figure 8 A flowchart illustrating an access control method 800 provided in an embodiment of this application;

[0067] Figure 9 A schematic diagram illustrating an inter-process access control process provided in an embodiment of this application;

[0068] Figure 10 This is a schematic diagram of the structure of a terminal 1000 provided in an embodiment of this application;

[0069] Figure 11 This is a schematic diagram of the structure of a computer program product 1100 provided in an embodiment of this application. Detailed Implementation

[0070] The embodiments of this application are described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. As those skilled in the art will understand, with the development of technology and the emergence of new scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0071] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in a sequence other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices. The naming or numbering of steps appearing in this application does not imply that the steps in the method flow must be performed in the chronological / logical order indicated by the naming or numbering. The execution order of named or numbered process steps can be changed according to the desired technical purpose, as long as the same or similar technical effect is achieved.

[0072] A sandbox is an execution environment that restricts program behavior according to security policies, providing an isolated environment for running applications. Sandbox environments are typically used to execute code from untested or untrusted third-party applications without compromising the operating system.

[0073] In related technologies, untrusted applications are run in a sandbox, and specific access requests initiated by these applications are intercepted to restrict their access to local user data or operating system resources. However, these technologies rely entirely on interception techniques to ensure the security of the sandbox environment. For some malicious programs that employ anti-interception techniques, these technologies may struggle to intercept the access requests initiated by the malicious programs, thus compromising system security.

[0074] In view of this, embodiments of this application provide an access control method that can be applied to a terminal. This method involves running an untrusted application on the terminal within an isolated process that lacks access permissions. The isolated process intercepts access requests initiated by the untrusted application. The isolated process forwards the intercepted access requests to an external process, which then verifies the untrusted application's permissions before executing the access request. Since the isolated process lacks access permissions by default, the access request is only executed if it is intercepted and the untrusted application possesses the necessary permissions. This solution prevents malicious programs from gaining access permissions through anti-interception techniques, thus ensuring system security.

[0075] The terminal involved in the embodiments of this application can be a terminal capable of running an isolation process. Exemplarily, this terminal can be, for example, a personal computer (PC), laptop computer, server, mobile phone, tablet computer, mobile internet device (MID), wearable device, virtual reality (VR) device, augmented reality (AR) device, wireless terminal in industrial control, wireless terminal in self-driving, wireless terminal in remote medical surgery, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, etc. This terminal can be a device running Android, iOS, Windows, or other systems. For ease of understanding, the following will use a smartphone running Android as an example to describe the access control method provided in the embodiments of this application.

[0076] Please refer to Figure 1 , Figure 1 This is a schematic diagram of the structure of a terminal 101 provided in an embodiment of this application. Figure 1 As shown, terminal 101 includes processor 103, which is coupled to system bus 105. Processor 103 can be one or more processors, each of which can include one or more processor cores. A video adapter 107 drives a display 109, which is coupled to system bus 105. System bus 105 is coupled to input / output (I / O) bus via bus bridge 111. I / O interface 115 is coupled to the I / O bus. I / O interface 115 communicates with various I / O devices, such as input device 117 (e.g., touchscreen), media tray 121 (e.g., compact disc read-only memory, CD-ROM, multimedia interface, etc.), transceiver 123 (capable of sending and / or receiving radio communication signals), camera 155 (capable of capturing still and moving digital video images), and external USB port 125. Optionally, the interface connected to I / O interface 115 can be a USB interface.

[0077] The processor 103 can be any conventional processor, including a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, or a combination thereof. Optionally, the processor can be a special-purpose device such as an ASIC.

[0078] Terminal 101 can communicate with software deployment server 149 via network interface 129. Exemplarily, network interface 129 is a hardware network interface, such as a network interface card (NIC). Network 127 can be an external network, such as the Internet, or an internal network, such as Ethernet or a virtual private network (VPN). Optionally, network 127 can also be a wireless network, such as a WiFi network or a cellular network.

[0079] Hard disk drive interface 131 is coupled to system bus 105. Hardware driver interface is connected to hard disk drive 133. System memory 135 is coupled to system bus 105. Data running in system memory 135 may include operating system (OS) 137, applications 143, and scheduling tables of terminal 101.

[0080] An operating system consists of the Shell 139 and the kernel 141. The Shell 139 is an interface between the user and the operating system kernel. The shell is the outermost layer of the operating system. The shell manages the interaction between the user and the operating system: waiting for user input, interpreting user input for the operating system, and processing various operating system outputs.

[0081] Kernel 141 consists of the parts of the operating system used to manage memory, files, peripherals, and system resources. Kernel 141 interacts directly with the hardware. The operating system kernel typically runs processes and provides inter-process communication, CPU time-slice management, interrupts, memory management, I / O management, and so on.

[0082] For example, when terminal 101 is a server, application 143 includes cloud computing-related programs. In one embodiment, when application 143 needs to be executed, terminal 101 can download application 143 from software deployment server 149. In one embodiment, when terminal 101 downloads application 143 from software deployment server 149, terminal 101 may also download a schedule corresponding to application 143 from software deployment server 149.

[0083] Please refer to Figure 2 , Figure 2 This is a schematic diagram illustrating an application scenario provided by an embodiment of this application. For example... Figure 2As shown, a host process and an isolated process run on the terminal, with the untrusted application running in the isolated process. The untrusted application running in the isolated process does not have permission to access resources on the terminal (such as system resources or user personal data). When the untrusted application initiates an access request to resources such as the network or file directories, the isolated process intercepts the access request and sends it to the host process. The host process verifies the access request's permissions. If the access request passes the permission verification, the host process executes the access request and returns the corresponding access result to the isolated process. The isolated process then returns the received access result to the untrusted application. If the access request fails the permission verification, the host process does not execute the access request and returns an error code to the isolated process. By running the untrusted application in the isolated process and having the host process proxy the untrusted application's access requests, it is possible to monitor the untrusted application's access to resources such as the network or file directories, preventing malicious programs from interfering with the normal operation of the system. Furthermore, since the isolation process has no access permissions by default, even if an untrusted application bypasses the isolation process's interception of access requests using anti-interception techniques, the untrusted application will still be unable to successfully execute the access request. This solution prevents malicious programs from gaining access permissions through anti-interception techniques, thus ensuring system security.

[0084] Please refer to Figure 3 , Figure 3 This is a flowchart illustrating an access control method 300 provided in an embodiment of this application. Figure 3 As shown, the method 300 includes the following steps 301-306.

[0085] Step 301: The second process obtains an access request from the target application, which runs in the second process, but the second process does not have permission to execute the access request.

[0086] In this embodiment, a first process and a second process run on the terminal, and the first process and the second process can communicate with each other. The first process has permission to access resources in the terminal (such as system resources or user personal data), while the second process does not have permission to access the external environment. Therefore, the second process can forward the obtained access request to the first process, which will then act as an agent to execute the access request.

[0087] For example, the first process can be a host process in the Android system, and the second process can be an isolated process in the Android system. The host process is used to establish a connection with the isolated process and manage and proxy the isolated process's access to the outside world. An isolated process is a special type of process in the Android system. Applications or services running in an isolated process do not have permission to access the external environment; that is, these applications or services are isolated from the rest of the system.

[0088] One or more applications can run in the second process, and the target application can be any application within the second process. When the target application needs to access system resources, such as network, file directories, or files under a specific path, the target application initiates an access request. This access request is used to request access to the system resources. System resources refer to the software resources, hardware resources, and data resources stored on the terminal.

[0089] Generally, in the low-level implementation of a system, access to system resources is typically achieved by calling interfaces provided by the system. Therefore, this access request can be, for example, a system call request. A system call refers to the interface between an application and the system, such as the program interface or application programming interface (API) provided by the operating system to the application. Applications communicate with the operating system and obtain its services through system calls. In other words, an application can initiate a system call request to request the execution of an interface provided by the operating system, thereby gaining access to system resources.

[0090] When the target application initiates an access request, the second process intercepts the request to obtain the access information from the target application. For example, the second process can be pre-configured with multiple system call numbers. When the second process recognizes that an access request from the target application includes the same system call number, it intercepts that request. It should be understood that because the operating system implements many different system calls, the application needs to pass a parameter named the system call number when initiating a system call request to identify the system call required by the application. In other words, the system call number is used to identify the type of system call that the application is requesting to execute.

[0091] Step 302: The second process sends the access request to the first process, and the first process has the permission to execute the access request.

[0092] Since the second process does not have permission to execute the access request, while the first process does, the second process can send an access request from the target application to the first process through inter-process communication.

[0093] The inter-process communication between the second process and the first process can take various forms, such as pipe communication, message queue communication, or shared memory communication. For example, a command transmission channel can be pre-established between the first and second processes. The second process can send access requests to the first process through this established command transmission channel. For instance, after initialization, the first process creates a command transmission channel and sends its identifier to the second process. Based on the received identifier, the second process can then send access requests to the first process through the command transmission channel.

[0094] In one possible embodiment, after receiving an access request from the target application, the second process can add information about the target application, such as its identifier, to the access request, thus obtaining a new access request. The second process then sends a new access request to the first process, including the target application's information, to facilitate permission verification by the first process. It should be understood that the target application information added by the second process to the access request can be inherent information of the target application itself, such as an identifier or name set during the target application's development. Alternatively, the target application information added by the second process can be an identifier assigned to the target application by either the second or first process. For example, during the initialization process of the first and second processes, either the first or second process can assign a unique identifier to the target application that needs to run in the second process, allowing the first process to determine the application initiating the access request based on the application's identifier carried in the access request.

[0095] In one possible embodiment, the second process can create a channel identifier pair based on the access request, the channel identifier pair including a third channel identifier and a fourth channel identifier. Then, the second process adds the third channel identifier to the access request from the target application and sends the access request with the added third channel identifier to the first process. The channel identifier pair corresponds to a data transmission channel used for data transmission between the first and second processes. When the first process receives the access request with the added third channel identifier, the first process writes the data to be returned into the data transmission channel corresponding to the third channel identifier. In this way, the second process can obtain the data returned by the first process based on the fourth channel identifier.

[0096] Understandably, the target application running in the second process may have multiple threads running concurrently. To ensure independent data transmission between these threads, the second process can create an independent data transmission channel for each thread, with each channel identified by a channel identifier pair. Thus, when the second process intercepts an access request from a thread in the target application, it can include the channel identifier corresponding to that thread in the request. This allows the first process to return data to the second process from the data transmission channel corresponding to that thread, ensuring data isolation between different threads, effectively preventing data corruption, and guaranteeing reliable data transmission.

[0097] Furthermore, after the second process creates an independent data transmission channel for the thread, it can add a thread identifier to the access request. This thread identifier identifies the thread initiating the access request; that is, the second process adds both a thread identifier and a channel identifier to the access request. Upon receiving an access request that includes both the thread identifier and the channel identifier, the first process establishes a correspondence between them. Thus, when the first process subsequently receives other access requests with the same thread identifier, it can determine the corresponding channel identifier based on the thread identifier and send the subsequent access results based on that channel identifier.

[0098] In other words, after receiving an access request from the target application, the second process can add information about the target application and the identifier of the data transmission channel allocated to it to the access request. The target application information in the access request is used by the first process to perform permission verification on the access request, while the data transmission channel identifier is used by the first process to return the result of executing the access request.

[0099] Step 303: The first process performs permission verification on the access request and obtains the verification result.

[0100] In this embodiment, the terminal can be configured with application access permission information. For example, the application access permission information may include the access permissions corresponding to each of the multiple applications on the terminal, such as application A having permission to access network resources, application B not having permission to access network resources, and application C having permission to access the system file directory. The application access permission information may also include access permissions corresponding to the application type, such as type A applications having permission to access network resources, type B applications not having permission to access network resources, and type C applications not having permission to access the system file directory. The first process obtains the access permission information of the applications configured on the terminal, performs permission verification on the access request, and obtains the verification result.

[0101] For example, the access request sent by the second process includes a system call number and information about the target application. The system call number represents a system call requested by the target application, and the target application information can be, for example, an identifier for the target application, used to identify the target application's identity or type. Thus, the first process can perform permission verification based on the system call number and the target application information. Specifically, the first process can query the access permission information of the applications configured in the terminal based on the system call number and the target application information. If the query result indicates that the target application has permission to access the system call corresponding to the system call number, the verification result can be determined as the target application having access permission; if the query result indicates that the target application does not have permission to access the system call corresponding to the system call number, the verification result can be determined as the target application not having access permission.

[0102] Step 304: Based on the verification result indicating that the target application has access rights, the first process executes the access request to obtain a target descriptor for accessing system resources.

[0103] If the verification result indicates that the target application has the necessary access permissions, the first process can proxy the access request, thereby obtaining a target descriptor for accessing the system resource. If the verification result indicates that the target application does not have the necessary access permissions, the first process can terminate the execution of the access request. The target descriptor is an abstract concept pointing to a system resource, used to identify the resource. The application can access the corresponding system resource through this target descriptor.

[0104] Step 305: The first process allocates a proxy descriptor to the target descriptor, and the target descriptor and the proxy descriptor have a corresponding relationship.

[0105] In this embodiment, when the second process acts as an isolated process to isolate itself from the external environment, the first process is typically unable to directly return a target descriptor (such as a socket descriptor or file descriptor) that directly points to a system resource to the second process due to the limitations of the isolated process itself. Therefore, the first process can allocate a proxy descriptor for the target descriptor, which has a corresponding relationship with the target descriptor. The first process can find the uniquely corresponding target descriptor based on the proxy descriptor.

[0106] Step 306: The first process sends the proxy descriptor to the second process.

[0107] If the access request sent by the second process includes a third channel identifier, the first process can send a proxy descriptor to the second process based on the data transmission channel corresponding to the third channel identifier to achieve data isolation between different threads.

[0108] Step 307: The second process sends the proxy descriptor to the target application.

[0109] In this embodiment, after receiving the access result returned by the first process, the second process forwards the access result returned by the first process to the target application.

[0110] In this embodiment, when the first process executes an access request from an untrusted application and obtains a target descriptor pointing to a system resource, the first process allocates a corresponding proxy descriptor for the target descriptor and returns the proxy descriptor to the untrusted application via the second process. In this way, the untrusted application in the second process can obtain the proxy descriptor corresponding to the target descriptor and access the system resource based on the proxy descriptor. Furthermore, when the untrusted application accesses the system resource through the proxy descriptor, it must have the first process replace the proxy descriptor with the target descriptor to complete the access. That is, by avoiding directly returning the target descriptor to the untrusted application, the first process ensures that the untrusted application's access to system resources can be effectively monitored, thus ensuring system security while enabling untrusted application access to system resources.

[0111] Please refer to Figure 4 , Figure 4 This is a flowchart illustrating an access control method 400 provided in an embodiment of this application. Figure 4 As shown, the method 400 includes the following steps 401-410.

[0112] Step 401: The second process sends a first system call request to the first process.

[0113] In this embodiment, the access request intercepted by the second process from the target application is specifically a first system call request, which is used to request an interface provided by the system. The second process does not have permission to execute system call requests, while the first process does.

[0114] For example, when the target application needs to access network resources, the first system call request may be used to request to initiate network access; when the target application needs to access files in the terminal directory, the first system call request may be used to request to open the directory file.

[0115] Step 402: The first process executes the first system call request and obtains the target descriptor used to access system resources.

[0116] After receiving the first system call request, the first process parses the request and verifies its permissions. Once the permissions are verified, the first process executes the system call and obtains the target descriptor.

[0117] For example, when the first system call request is used to initiate network access, the target descriptor can be a socket descriptor. A socket is an abstraction of an endpoint for bidirectional communication between application processes on different hosts in a network; that is, a socket is the interface through which an application communicates via network protocols. Generally, when an application creates a socket for network communication, the operating system returns a small integer as a descriptor to identify the socket. The application can then use this socket descriptor to reference the socket, thereby enabling network access. In other words, when the first process executes the first system call request to initiate network access, the operating system returns a socket descriptor to the first process to identify the socket.

[0118] For example, when the first system call request is used to request access to a file, the target descriptor can be a file descriptor. A file descriptor is formally a non-negative integer. In practice, a file descriptor is an index value pointing to a record table maintained by the operating system for each process, showing the files opened by that process. When a process opens an existing file or creates a new file, the operating system returns a file descriptor to the process to identify the file opened or created by the process. The process also needs to use the file descriptor to specify the file to be read or written. That is, when the first process executes the first system call request to access a file, the operating system returns a socket descriptor to the first process to identify the socket.

[0119] Step 403: The first process allocates a proxy descriptor to the target descriptor, and the target descriptor and the proxy descriptor have a corresponding relationship.

[0120] In this embodiment, when the second process acts as an isolated process to isolate itself from the external environment, the first process is typically unable to directly return a target descriptor (such as a socket descriptor or file descriptor) that directly points to a system resource to the second process due to the limitations of the isolated process itself. Therefore, the first process can allocate a proxy descriptor for the target descriptor, which has a corresponding relationship with the target descriptor. The first process can find the uniquely corresponding target descriptor based on the proxy descriptor.

[0121] Step 404: The first process sends the proxy descriptor to the second process.

[0122] After allocating a corresponding proxy descriptor to the target descriptor, the first process sends the proxy descriptor to the second process as a response to the first system call request.

[0123] Step 405: The second process sends the proxy descriptor to the target application.

[0124] Step 406: The second process sends a second system call request to the first process.

[0125] After the second process returns a proxy descriptor to the target application, the target application can initiate a second system call request based on the proxy descriptor. This second system call request includes the proxy descriptor to request access to the system resources corresponding to the proxy descriptor. For example, if the first system call request is used to request network access, the target application can initiate a second system call request based on the proxy descriptor to request the establishment of a network connection. Similarly, if the first system call request is used to request opening a directory file, the target application can initiate a second system call request based on the proxy descriptor to request traversal of the directory file.

[0126] Therefore, after intercepting the second system call request from the target application, the second process also sends the second system call request to the first process. Specifically, before sending the second system call request, the second process can add an identifier of the thread in the target application that initiated the second system call request to the second system call request, so that the first process can return the result obtained from executing the second system call request to the second process based on the data transmission channel corresponding to the thread identifier.

[0127] Step 407: The first process obtains the target descriptor corresponding to the proxy descriptor.

[0128] After receiving a second system call request that includes a proxy descriptor, the first process parses the request to obtain the proxy descriptor. Then, since the first process has established a mapping between proxy descriptors and target descriptors, it can retrieve the target descriptor corresponding to the proxy descriptor by looking up the mapping. This target descriptor is used by the first process to subsequently execute the second system call request.

[0129] Step 408: The first process executes the second system call request according to the target descriptor and obtains the resource access result.

[0130] Understandably, after the first process finds the target descriptor corresponding to the proxy descriptor in the second system call request, the first process can execute the second system call request based on the target descriptor and obtain the resource access result. For example, when the second system call request is used to request the establishment of a network connection, the first process can establish a connection with the corresponding network site based on the socket descriptor corresponding to the proxy descriptor and obtain the status information returned by the network site indicating a successful connection; this status information is the obtained resource access result. When the first system call request is used to request the traversal of directory files, the target application can traverse the directory files based on the target descriptor and obtain the traversal result, which is the obtained resource access result.

[0131] In one possible implementation, since the first process can find the target descriptor corresponding to the proxy descriptor in the second system call, it means that the first process has performed permission verification on the target application and the verification result is successful. Because the target application can only obtain the proxy descriptor corresponding to the target descriptor if the permission verification is successful, the first process can avoid performing permission verification on the second system call request to save resource overhead.

[0132] Step 409: The first process sends the resource access result to the second process.

[0133] Step 410: The second process sends the resource access result to the target application.

[0134] Similarly, after obtaining the resource access result, the first process returns the resource access result to the second process, so that the second process can further forward the resource access result to the target application. Steps 409-410 are similar to steps 305-306 described above, and will not be repeated here.

[0135] In this embodiment, when the first process executes a system call request and obtains a target descriptor pointing to a system resource, it allocates a corresponding proxy descriptor for the target descriptor and returns the proxy descriptor to the second process. Thus, the untrusted application in the second process only obtains the proxy descriptor corresponding to the target descriptor. When the untrusted application initiates access to the system resource based on the proxy descriptor, it must have the first process replace the proxy descriptor with the target descriptor to complete the access. In other words, by avoiding directly returning the target descriptor to the untrusted application, the first process ensures that the untrusted application's access to system resources can be effectively monitored, thereby guaranteeing system security.

[0136] The above describes the process of the first and second processes controlling access to system call requests. To facilitate understanding, the following will use specific examples to illustrate the process of the first and second processes controlling access to different system call requests.

[0137] Please refer to Figure 5a , Figure 5a This is a flowchart illustrating an access control method 500 provided in an embodiment of this application. Figure 5a As shown, the method 500 includes the following steps 501-510.

[0138] Step 501: Thread 1 in the target application initiates system call request 1, which is used to request network access.

[0139] During the execution of the target application in the second process, the target application creates thread 1. During the execution of thread 1, when thread 1 needs to request network access, thread 1 initiates system call request 1. System call request 1 is used to request network access. For example, system call request 1 may specifically include a system call number, and the name corresponding to this system call number is "socket," meaning that system call request 1 requests the socket for network access.

[0140] Step 502: The second process intercepts system call request 1 from thread 1 in the target application.

[0141] Since system call request 1 includes the system call number that requests network access, the second process can intercept system call request 1 from thread 1 in the target application based on the system call number.

[0142] Step 503: The second process creates data transmission channel 1 for thread 1.

[0143] To ensure that data subsequently returned by the first process to thread 1 can be transmitted independently, the second process can create an independent data transmission channel 1 for thread 1. This data transmission channel 1 can be understood as a data return channel, through which the first process can transmit the data returned to the second process. For example, after creating data transmission channel 1, the second process obtains a pair of channel identifiers corresponding to data transmission channel 1, such as the third and fourth channel identifiers described in the above embodiment. The second process can send one of the channel identifiers corresponding to data transmission channel 1 to the first process. Thus, when the first process writes data to data transmission channel 1 using one of the channel identifiers, the second process can read the data written by the first process from data transmission channel 1 using the other channel identifier, thereby achieving data transmission.

[0144] Step 504: The second process adds the identifier of data transmission channel 1 and the identifier of thread 1 to system call request 1, and obtains system call request 2.

[0145] The identifier of data transmission channel 1 added by the second process in system call request 1 is a channel identifier, that is, one of the two channel identifiers corresponding to data transmission channel 1, such as the third channel identifier described in the above embodiment.

[0146] Furthermore, the second process can also add information about the target application to system call request 1, such as the target application's identifier, which is used to identify the target application's identity or type. The target application's identifier can be, for example, a unique identifier or name set during the target application's development; or it can be an identifier assigned to the target application by the second process or the first process.

[0147] Step 505: The second process sends system call request 2 to the first process.

[0148] Step 506: The first process parses system call request 2 and performs permission verification on system call request 2.

[0149] Since system call request 2 includes the system call number and the target application's information, the first process can perform permission verification on system call request 2 based on the system call number and the target application's information to determine whether the target application has the permission to request and execute system call request 2.

[0150] In addition, after parsing system call request 2, the first process can obtain the identifier of data transmission channel 1 and the identifier of thread 1 in system call request 2. The first process establishes a correspondence between the identifier of data transmission channel 1 and the identifier of thread 1 so that when other requests including the identifier of thread 1 are received in the future, the corresponding data transmission channel 1 can be determined.

[0151] Step 507: After system call request 2 passes the permission verification, the first process executes system call request 2 and obtains the socket descriptor.

[0152] Since system call request 2 is used to request network access, after the first process executes system call request 2, it can obtain the socket descriptor returned by the operating system for performing network access.

[0153] Step 508: The first process allocates a channel identifier pair for the socket descriptor, which includes channel identifier 1 and channel identifier 2.

[0154] The channel identifier pair allocated by the first process is used for data transmission between the first process and the target application. The channel identifier pair includes channel identifier 1 and channel identifier 2, which can be, for example, the first channel identifier and the second channel identifier described in the above embodiments. After allocating the channel identifier pair, the first process can also establish a correspondence between the socket descriptor and the channel identifier pair, for example, by saving the socket descriptor and the channel identifier pair to a mapping table, so that the first process can find the corresponding socket descriptor based on any one of the channel identifiers in the channel identifier pair.

[0155] Step 509: The first process sends channel identifier 1 to the second process.

[0156] After the first process allocates a channel identifier pair for the socket descriptor, it returns one of the channel identifiers in the pair, such as channel identifier 1, to the second process. Specifically, the first process can send channel identifier 1 to the second process based on the identifier of data transmission channel 1 in system call request 2; that is, the first process transmits channel identifier 1 through data transmission channel 1.

[0157] Step 510: The second process sends channel identifier 1 to thread 1 of the target application.

[0158] After receiving channel identifier 1 through data transmission channel 1, the second process returns channel identifier 1 to thread 1 of the target application, so that thread 1 can initiate a request to establish a network connection based on channel identifier 1.

[0159] Please refer to Figure 5b , Figure 5b This is another flowchart illustrating an access control method 500 provided in an embodiment of this application. For example... Figure 5b As shown, the method 500 further includes the following steps 511-521.

[0160] Step 511: The second process intercepts system call request 3 from thread 1 in the target application.

[0161] For thread 1, the channel identifier 1 returned by the first process is essentially a socket descriptor, meaning thread 1 can use channel identifier 1 to access the network. After thread 1 obtains channel identifier 1, if it needs to access a specific network site, it also needs to request and establish a connection with the network site based on channel identifier 1. Therefore, thread 1 can initiate system call request 3, which includes channel identifier 1 and the address of the network site. System call request 3 is used to request and establish a connection with that network site. For example, system call request 3 may specifically include a system call number and parameters (i.e., the address of the network site) used to execute system call request 3. The name corresponding to the system call number is connect, meaning system call request 3 is used to request and establish a connection with the network site.

[0162] Step 512: The second process adds the identifier of thread 1 to system call request 3 and obtains system call request 4.

[0163] To facilitate the first process in identifying the thread that initiated the system call request, the second process can add the identifier of thread 1 to system call request 3 to obtain system call request 4.

[0164] In one possible embodiment, since system call request 3 includes channel identifier 1, and channel identifier 1 corresponds to a socket descriptor, the first process can also determine the thread initiating the system call request through channel identifier 1. Therefore, the second process may not need to include the thread 1 identifier in system call request 3.

[0165] Step 513: The second process sends a system call request 4 to the first process.

[0166] Step 514: The first process finds the corresponding socket descriptor based on the channel identifier 1 in system call request 4.

[0167] Since the first process establishes a correspondence between channel identifiers and socket descriptors, such as the mapping table described in the above embodiment, after parsing system call request 4 and obtaining channel identifier 1, the first process can find the corresponding socket descriptor based on channel identifier 1.

[0168] Step 515: The first process executes system call request 4 based on the socket descriptor to obtain the connection status information with the network site.

[0169] After parsing system call request 4, the first process can also obtain the parameters included in system call request 4, namely the address of the aforementioned network site. Thus, the first process can execute system call request 4 based on the socket descriptor and the network site's address, i.e., establish a connection with the network site. After the first process successfully establishes a connection with the network site, it can receive connection status information returned by the network site, which indicates that the network connection was successful.

[0170] Step 516: The first process establishes a listener for channel identifier 1.

[0171] In this embodiment, after the first process successfully establishes a connection with the network site based on the socket descriptor, the first process acts as a proxy between the network site and thread 1 of the target application, responsible for forwarding data from thread 1 to the network site and vice versa. Channel identifier 1 and channel identifier 2 correspond to the channels through which data is transmitted between the first process and thread 1. Since the resources of channel identifiers and socket descriptors are limited, thread 1 will close channel identifier 1 to release system resources when it does not need to perform network access. Therefore, to promptly detect thread 1's closing operation of channel identifier 1, the first process can establish a listener for channel identifier 1. When thread 1 closes channel identifier 1, the first process will receive callback information returned by the listener, which indicates that thread 1 has closed channel identifier 1.

[0172] Furthermore, the first process can also establish a listener for the socket descriptor. Thus, when the socket descriptor is closed, the first process can receive a message sent by the listener, indicating that the socket descriptor has been closed. The first process then closes the proxy descriptor corresponding to the socket descriptor based on the message.

[0173] It is understandable that during the target application's network access process, external factors may cause network interruption, preventing the target application from accessing the network. In this case, to promptly reclaim system resources, the first process can monitor the socket descriptor through a listener. If the socket descriptor is closed, it can be considered a network interruption, thus triggering the first process to close the proxy descriptor corresponding to the socket descriptor, thereby promptly reclaiming system resources.

[0174] In this system, listeners are used to monitor the occurrence of a specific event (program). When the monitored event actually occurs, the event originator (i.e., the event source) sends a message to the listener registered for that event, thus informing the listener of certain information. Simultaneously, the listener also receives an event object, which allows it to access relevant attributes and perform related operations, such as sending callback information to the process that registered the listener.

[0175] Step 517: The first process sends connection status information to the second process.

[0176] After the first process obtains the connection status information returned by the network site, it can send the connection status information to the second process through data transmission channel 1 corresponding to thread 1. For example, when the system call request 4 sent by the second process includes the identifier of thread 1, the first process looks up the corresponding data transmission channel based on the identifier of thread 1, and then sends the connection status information based on the found data transmission channel 1.

[0177] Step 518: The second process sends connection status information to thread 1 of the target application.

[0178] In this embodiment, after the second process returns connection status information to thread 1 of the target application, thread 1 can determine that the connection with the network site has been successful. Therefore, thread 1 can interact with the network site based on channel identifier 1.

[0179] For example, when thread 1 needs to send data to a network site, thread 1 writes the data to be sent into the data transmission channel corresponding to channel identifier 1. Then, the first process can read the data sent by thread 1 into the data transmission channel based on channel identifier 2. Next, the first process looks up the socket descriptor corresponding to channel identifier 2 and sends the read data to the network site based on that socket descriptor. When the network site returns network data to the first process, the first process writes the data returned by the network site into the data transmission channel corresponding to channel identifier 2. Thus, thread 1 can read the data returned by the first process into the data transmission channel based on channel identifier 1. In other words, the first process acts as an intermediary between thread 1 and the network site. The first process interacts with the network site through socket descriptors, and the interaction between the first process and thread 1 is achieved through channel identifiers 1 and 2, ultimately realizing data interaction between the network site and thread 1.

[0180] In this embodiment, since thread 1 in the target application may need to exchange a large amount of data with the network site, the first process can allocate a channel identifier pair for the obtained socket descriptor after executing system call request 2 to initiate network access. Thus, after the first process returns one channel identifier from the channel identifier pair to thread 1, thread 1 can subsequently communicate with the first process based on that channel identifier. That is, when thread 1 needs to exchange data with the network site, thread 1 and the first process exchange data through the allocated channel identifier pair, and the first process then exchanges data with the network site. In this way, data sent from thread 1 to the network site does not need to be intercepted by the second process and then forwarded to the first process; data returned from the first process to thread 1 also does not need to be forwarded by the second process. Thread 1 and the first process can exchange data based on the channel identifier pair.

[0181] In simple terms, the first process allocates channel identifier pairs and returns one of the channel identifiers from the pair to the target application, enabling communication between the first process and the target application based on the channel corresponding to the channel identifier pair. This avoids the second process continuously forwarding large amounts of network data exchanged between the first process and the target application, improving data transmission efficiency. Furthermore, the data exchanged between the target application and the network site is transmitted through an independent channel, ensuring the reliability of data transmission.

[0182] Step 519: Thread 1 of the target application closes channel identifier 1.

[0183] When thread 1 of the target application finishes accessing the website, thread 1 closes the channel identifier 1 used for data interaction with the website. Simply put, when thread 1 no longer needs channel identifier 1, it can call the `close` function to close access to the website and release channel identifier 1 for reuse.

[0184] Step 520: The first process receives the callback information returned by the listener, which indicates that channel identifier 1 has been closed.

[0185] Since the first process has set up a listener to monitor channel identifier 1, when thread 1 closes channel identifier 1, the listener returns a callback message to the first process to indicate that channel identifier 1 has been closed.

[0186] Step 521: The first process closes the socket descriptor corresponding to channel identifier 1.

[0187] Based on the callback information returned by the listener, the first process finds the channel identifier 2 and socket descriptor corresponding to channel identifier 1. Then, the first process closes channel identifier 2 and socket descriptor to reclaim system resources in a timely manner.

[0188] Please refer to Figure 6a , Figure 6a This is a flowchart illustrating an access control method 600 provided in an embodiment of this application. Figure 6a As shown, the method 600 includes the following steps 601-610.

[0189] Step 601: Thread 2 in the target application initiates system call request 5, which requests to open the target file.

[0190] While the target application is running in the second process, it can also create thread 2, which is a separate thread from thread 1. During the execution of thread 2, when thread 2 needs to request to open a file, it initiates system call request 5. System call request 5 is used to request to open the target file. The target file can be, for example, a directory file or a specific file. For example, system call request 5 may include a system call number and parameters. The system call number corresponds to the name "open," and the parameter includes the path to the target file.

[0191] Step 602: The second process intercepts system call request 5 from thread 2 in the target application.

[0192] Since system call request 5 includes the system call number requesting to open the target file, the second process can intercept system call request 5 from thread 2 in the target application based on the system call number.

[0193] Step 603: The second process creates data transmission channel 2 for thread 2.

[0194] To ensure that data subsequently returned by the first process to thread 2 can be transmitted independently, the second process can create an independent data transmission channel 2 for thread 1. This data transmission channel 2 can be understood as a data return channel, through which the first process can transmit data to be returned to the second process. In other words, for data that needs to be returned to thread 1, the first process transmits it through data transmission channel 1; for data that needs to be returned to thread 2, the first process transmits it through data transmission channel 2, thereby achieving data isolation between different threads.

[0195] The way the second thread creates data transmission channel 2 for thread 2 is similar to the way the second thread creates data transmission channel 1 for thread 1. For details, please refer to step 503 above, which will not be repeated here.

[0196] Step 604: The second process adds the identifier of data transmission channel 2 and the identifier of thread 2 to system call request 5, and obtains system call request 6.

[0197] In one possible embodiment, the second process may also add information about the target application in system call request 5, such as the identifier of the target application, which is used to identify the identity information of the target application or to identify the type to which the target application belongs.

[0198] Step 605: The second process sends a system call request 6 to the first process.

[0199] Step 606: The first process parses system call request 6 and performs permission verification on system call request 6.

[0200] Since system call request 6 includes the system call number and information about the target application, the first process can perform permission verification on system call request 6 based on the system call number and the information about the target application to determine whether the target application has the permission to request the execution of system call request 6.

[0201] In addition, after parsing system call request 6, the first process can obtain the identifier of data transmission channel 2 and the identifier of thread 2 in system call request 6. The first process also establishes a correspondence between the identifier of data transmission channel 2 and the identifier of thread 2 so that when other requests including the identifier of thread 2 are received in the future, the corresponding data transmission channel 2 can be determined.

[0202] Step 607: After system call request 6 passes the permission verification, the first process executes system call request 6 and obtains the file descriptor.

[0203] Since system call request 6 is used to request the opening of a target file, the first process, after executing system call request 6, can obtain a file descriptor returned by the operating system for accessing the target file. For example, when system call request 6 is specifically used to request the opening of a directory file, the first process executes system call request 6 and obtains the directory file descriptor.

[0204] Step 608: The first process allocates a proxy file descriptor for the file descriptor and establishes a listener for the proxy file descriptor.

[0205] After allocating the proxy file descriptor, the first process can also establish a correspondence between the file descriptor and the proxy file descriptor, for example, by saving the file descriptor and the proxy file descriptor in a mapping table so that the first process can find the corresponding file descriptor based on the proxy file descriptor.

[0206] In addition, after a proxy file descriptor is assigned to a file descriptor, the first process can set up a listener for the proxy file descriptor so that the first process can detect the target application's operation of closing the proxy file descriptor in a timely manner.

[0207] Step 609: The first process sends the proxy file descriptor to the second process.

[0208] Specifically, the first process can send a proxy file descriptor to the second process based on the identifier of data transmission channel 2 in system call request 6, that is, the first process transmits the proxy file descriptor through data transmission channel 2.

[0209] Step 610: The second process sends a proxy file descriptor to thread 2 of the target application.

[0210] After receiving the proxy file descriptor through data transmission channel 2, the second process returns the proxy file descriptor to thread 2 of the target application, so that thread 2 can initiate a request to access the target file based on the proxy file descriptor.

[0211] Please refer to Figure 6b , Figure 6b This is another flowchart illustrating an access control method 600 provided in an embodiment of this application. Figure 6b As shown, the method 600 further includes the following steps 611-620.

[0212] Step 611: The second process intercepts system call request 7 from thread 2 in the target application.

[0213] After thread 2 obtains the proxy file descriptor, it can request access to the target file based on this descriptor. Therefore, thread 2 can initiate system call request 7, which includes the proxy file descriptor and is used to request access to the target file. For example, when the target file is a directory file and thread 2 requests to traverse the directory, system call request 7 may specifically include a system call number, with the name corresponding to that system call number being `getdents`.

[0214] Step 612: The second process adds the identifier of thread 2 to system call request 7, and obtains system call request 8.

[0215] To facilitate the first process in identifying the thread that initiated the system call request, the second process can add the identifier of thread 2 to system call request 7 to obtain system call request 8.

[0216] In one possible embodiment, since system call request 7 includes a proxy file descriptor, and a correspondence is established between the proxy file descriptor and the socket descriptor, the first process can actually determine the thread initiating the system call request through the proxy file descriptor. Therefore, the second process may not need to add the thread 2 identifier to system call request 7.

[0217] Step 613: The second process sends a system call request 8 to the first process.

[0218] Step 614: The first process finds the corresponding file descriptor based on the proxy file descriptor in system call request 8.

[0219] Since the first process establishes a correspondence between proxy file descriptors and file descriptors, such as the mapping table described in the above embodiment, after parsing system call request 8 and obtaining the proxy file descriptor, the first process can find the corresponding file descriptor based on the proxy file descriptor.

[0220] Step 615: The first process executes system call request 8 based on the file descriptor to obtain the access result of the target file.

[0221] For example, if the file descriptor is specifically a directory file descriptor, the first process can obtain the traversal results of the directory file by executing system call request 8 based on the directory file descriptor.

[0222] Step 616: The first process sends the access result of the target file to the second process.

[0223] After the first process obtains the access result of the target file, the first process can send connection status information to the second process through data transmission channel 2 corresponding to thread 2.

[0224] Step 617: The second process sends the access result of the target file to thread 2 of the target application.

[0225] Step 618: Thread 2 of the target application closes the proxy file descriptor.

[0226] When thread 2 of the target application no longer needs to access the target file, thread 2 closes the proxy file descriptor used to access the target file. For example, when thread 2 calls the `close` function to close the proxy file descriptor, it releases the proxy file descriptor for reuse.

[0227] In step 619, the first process receives the callback information returned by the listener, which indicates that the agent file descriptor has been closed.

[0228] Since the first process set up a listener to monitor the proxy file descriptor, when thread 2 closes the proxy file descriptor, the listener returns a callback message to the first process to indicate that the proxy file descriptor has been closed.

[0229] Step 620: The first process closes the file descriptor corresponding to the proxy file descriptor.

[0230] Based on the callback information returned by the listener, the first process locates the file descriptor corresponding to the proxy file descriptor. Then, the first process closes the file descriptor to reclaim system resources in a timely manner. It's understandable that the number of file descriptors allocated for a given file in the system is finite. That is, the system can return different file descriptors to multiple threads simultaneously accessing the target file, and different file descriptors can point to the same target file. However, the number of different file descriptors the system can return for the same target file is limited. Therefore, when a thread no longer needs to access the target file, it needs to close the file descriptor to facilitate the reclamation of system resources.

[0231] In this embodiment, the first process can promptly detect the behavior of thread 2 closing the proxy file descriptor by establishing a listener for the proxy file descriptor, and then promptly close the file descriptor corresponding to the proxy file descriptor to realize the timely reclamation of system resources.

[0232] The above describes the process of the first and second processes controlling access to different system call requests. The following will take the Android system as an example and introduce the process of controlling access to system call requests through two processes in combination with specific application scenarios.

[0233] Please refer to Figure 7 , Figure 7 This is a flowchart illustrating an access control method 700 provided in an embodiment of this application.

[0234] Step 701: The client requests to register a time fence during sunrise or sunset using the Awareness Kit service.

[0235] In this embodiment, the client can refer to an application running on the terminal. During operation, this application requests to register the inSunriseOrSunsetPeriod time fence using the Awareness Kit service. Awareness Kit is a context-aware service that supports the acquisition of a combination of context-aware capabilities, including the user's current time and space, location, activity status, audio device status, ambient light, weather, and beacons. By utilizing the capabilities supported by the Awareness Kit service, the application can more efficiently obtain the user's current context, thereby providing a more intelligent experience. Furthermore, the inSunriseOrSunsetPeriod time fence is a service that sets a time alarm. When the terminal is within a certain period of local sunrise or sunset (e.g., 30 minutes before sunrise), the time fence's state is set to True; otherwise, the time fence's state is set to False.

[0236] Step 702: The system starts the host process, and the host process starts the isolation process.

[0237] For the terminal, since the Awareness Kit service requested by the client is an untrusted application, the system on the terminal starts a host process, which in turn starts an isolation process to run the Awareness Kit service. After the host process starts the isolation process, it can create a service stub proxy to handle the data exchanged between the inSunriseOrSunsetPeriod time fence in the isolation process and the client. Furthermore, the host process can establish a command channel between itself and the isolation process and send the corresponding channel identifier to the isolation process. This allows the isolation process to send access requests to the host process via the command channel.

[0238] In one possible embodiment, since the purpose of the host process initiating the isolation process is to load the Awareness Kit service within the isolation process, the host process is actually aware of the service loaded within the isolation process. In this case, the host process can assign a unique identifier to the Awareness Kit service that needs to be loaded within the isolation process to identify the service running within the isolation process. In this way, even when multiple isolation processes are connected, the host process can still determine the service or application running within an isolation process based on the identifier sent by the isolation process.

[0239] Step 703: The isolation process loads the Awareness Kit service.

[0240] After the isolation process is started by the host process, it accepts commands from the host process and loads the Awareness Kit service. The Awareness Kit service within the isolation process registers the inSunriseOrSunsetPeriod time fence. Since the inSunriseOrSunsetPeriod time fence needs to obtain the sunrise or sunset time of the terminal's current location, its working logic is as follows: first, it checks if a valid sunrise or sunset time exists in the terminal's local data; this check involves traversing directory files. If the check confirms that a valid sunrise or sunset time exists in the terminal's local data, it then proceeds to read the database file. Both of these processes involve initiating relevant system call requests.

[0241] Step 704: The inSunriseOrSunsetPeriod time fence in the Awareness Kit service initiates a system call request to open the directory file.

[0242] During the isolation process, the inSunriseOrSunsetPeriod time fence initiates a system call request to open a directory file to determine whether valid sunrise or sunset times exist in the terminal's local data. Specifically, the system call request initiated by the inSunriseOrSunsetPeriod time fence can include a system call number and parameters. The system call number corresponds to the name "open," and the parameter includes the path to the directory file.

[0243] Step 705: The isolation process intercepts the system call request initiated by the inSunriseOrSunsetPeriod time fence.

[0244] Based on the system number in the system call request, the isolation process can intercept system call requests initiated by the inSunriseOrSunsetPeriod time fence.

[0245] Step 706: The isolated process sends a system call request to the host process.

[0246] After intercepting the system call request initiated by the inSunriseOrSunsetPeriod time fence, the isolation process creates a data transmission channel for the inSunriseOrSunsetPeriod time fence and obtains the identifier of this data transmission channel. Then, the isolation process adds the identifier of this data transmission channel, the identifier of the inSunriseOrSunsetPeriod time fence, and the identifier of the Awareness Kit service to the system call request, resulting in an updated system call request. The isolation process then sends the updated system call request to the host process through the command channel.

[0247] Step 707: The host process executes the system call request.

[0248] The host process receives and parses system call requests sent by the isolated process, then creates a task thread for the system call and adds it to the thread pool for unified management and execution of the corresponding system call requests. Specifically, the host process executes a system call request to open a directory file and obtains the corresponding response.

[0249] Step 708: The host process returns a response request to the isolation process.

[0250] After receiving the response to the system call request, the host process, based on the identifier of the data transmission channel sent by the isolated process, sends a response request to the isolated process through the corresponding data transmission channel. Upon receiving the response request, the isolated process returns the response to the `inSunriseOrSunsetPeriod` time fence. Finally, the `inSunriseOrSunsetPeriod` time fence determines that the local data is valid based on the response, and then initiates a system call request to read the database file. The steps after the `inSunriseOrSunsetPeriod` time fence initiates the system call request to read the database file are similar to steps 704-708 above, and will not be repeated here.

[0251] When the inSunriseOrSunsetPeriod time fence obtains the final response result based on the system call request, the isolated process returns the response result to the client through the service stub proxy in the host process.

[0252] Please refer to Figure 8 , Figure 8 This is a flowchart illustrating an access control method 800 provided in an embodiment of this application.

[0253] Step 801: The client requests to use the Awareness Kit service to call the weather snapshot interface to get the device weather (getWeatherByDevice).

[0254] In this embodiment, the client can refer to an application running on the terminal. During operation, this application requests the use of the Awareness Kit service to call the getWeatherByDevice weather snapshot interface. For example, the client in this embodiment can be the same client as the client in method 800. The getWeatherByDevice weather snapshot interface is a service whose function is to query the weather status of the terminal's current location via the network.

[0255] Step 802: The host process receives the client's request and notifies the isolation process to create the task thread corresponding to the getWeatherByDevice weather snapshot interface.

[0256] In this embodiment, if the client is the same as the client in method 800, since the client has started the host process in method 800, the client can also directly send instructions to the host process so that the host process notifies the isolation process to create the task thread corresponding to the getWeatherByDevice weather snapshot interface.

[0257] After the host process notifies the isolated process 2 to create a new task thread, another service stub proxy can be created in the host process. This service stub proxy is used to proxy the data exchanged between the getWeatherByDevice weather snapshot interface in the isolated process and the client.

[0258] Step 803: The Awareness Kit service in the isolation process creates a task thread corresponding to the getWeatherByDevice weather snapshot interface.

[0259] Since the getWeatherByDevice weather snapshot API needs to obtain the weather at the current location of the terminal, it needs to access a website to obtain the weather information on the website.

[0260] Step 804: The getWeatherByDevice weather snapshot interface in the Awareness Kit service initiates a system call request to establish network access.

[0261] During the isolation process, the `getWeatherByDevice` weather snapshot interface initiates a system call request to establish network access in order to obtain the weather status on the website. Specifically, the system call request initiated by the `getWeatherByDevice` interface may include a system call number, the name of which is a socket.

[0262] Step 805: The isolated process intercepts the system call request initiated by the getWeatherByDevice weather snapshot interface.

[0263] Based on the system number in the system call request, the isolated process can intercept the system call request initiated by the getWeatherByDevice weather snapshot interface.

[0264] Step 806: The isolated process sends a system call request to the host process.

[0265] After intercepting the system call request initiated by the `getWeatherByDevice` weather snapshot interface, the isolation process creates another data transmission channel for the `getWeatherByDevice` interface and obtains the identifier of this data transmission channel. Then, the isolation process adds the identifier of this data transmission channel, the identifier of the `getWeatherByDevice` weather snapshot interface, and the identifier of the Awareness Kit service to the system call request, resulting in an updated system call request. The isolation process then sends the updated system call request to the host process through the command channel.

[0266] Step 807: The host process executes the system call request.

[0267] The host process receives and parses system call requests sent by the isolated process, then creates a task thread for the system call and adds it to the thread pool for unified management and execution of the corresponding system call requests. Specifically, the host process executes a system call request to open a directory file and obtains the corresponding response.

[0268] Step 808: The host process returns a response request to the isolation process.

[0269] After receiving the response to the system call request, the host process sends a response request to the isolated process through the corresponding data transmission channel, based on the identifier of the data transmission channel sent by the isolated process. Upon receiving the response request, the isolated process returns the response to the `getWeatherByDevice` weather snapshot interface. Finally, the `getWeatherByDevice` interface initiates a system call request to establish a connection with the network site based on the response. The steps after the `getWeatherByDevice` interface initiates the system call request to establish a connection with the network site are similar to steps 804-808 described above, and will not be repeated here.

[0270] When the getWeatherByDevice weather snapshot API receives the final response result based on the system call request, the isolated process returns the response result to the client through the service stub proxy in the host process.

[0271] The above describes the process of controlling access requests through inter-process interaction. For ease of understanding, the following section will describe the process of controlling access requests in detail from the internal implementation perspective.

[0272] Please refer to Figure 9 , Figure 9 This is a schematic diagram illustrating an inter-process access control process provided in an embodiment of this application. Figure 9 As shown, an untrusted application runs within the isolated process. Task threads within this untrusted application initiate system call requests during execution, such as those named "socket" or "connect." The management service thread within the isolated process includes a request redirection module and an execution module. The request redirection module intercepts the system call requests initiated by the untrusted application and repackages them, resulting in a repackaged system call request. This repackaged request includes information about the untrusted application, the data channel identifier, and the identifier of the task thread within the untrusted application. The request redirection module then passes the repackaged system call request to the execution module for redirection. The execution module sends the repackaged system call request to the host process via a command channel and awaits a callback from the host process.

[0273] The host process also includes a management service thread. The channel listening module within this thread listens to the command channel in a polling manner. Upon receiving a system call request from the isolated process, the management service thread creates a thread for that system call request and adds the newly created thread to the thread pool. The newly added thread in the thread pool is used to execute the system call request, specifically: parsing the system call request to obtain parameters and proxy descriptors; then translating the proxy descriptors to obtain the corresponding target descriptors; finally, based on the obtained parameters and target descriptors, executing the parsed system call request and sending the response back to the isolated process via the data channel. Thus, the execution module in the isolated process reads the callback information from the data channel, parses the call result, and returns it to the untrusted application.

[0274] exist Figures 1 to 9 Based on the corresponding embodiments, in order to better implement the above-described solutions of the embodiments of this application, related equipment for implementing the above-described solutions is also provided below.

[0275] For details, please refer to [link / reference]. Figure 10 , Figure 10 This application provides a schematic diagram of the structure of a terminal 1000, which includes a transceiver unit 1001 and a processing unit 1002. The transceiver unit 1001 receives an access request sent by a second process, the access request originating from a target application running in the second process, where the second process does not have permission to execute the access request. The processing unit 1002 executes the first access request to obtain a target descriptor for accessing system resources. The processing unit 1002 is further configured to allocate a proxy descriptor to the target descriptor, the target descriptor and the proxy descriptor having a corresponding relationship. The transceiver unit 1001 is also configured to send the proxy descriptor to the second process.

[0276] In one possible implementation, the transceiver unit 1001 is further configured to receive a second access request sent by a second process, the second access request including the proxy descriptor, the second access request being used to request access to system resources; the processing unit 1002 is further configured to obtain the target descriptor corresponding to the proxy descriptor; the processing unit 1002 is further configured to execute the second access request according to the target descriptor to obtain a resource access result; the transceiver unit 1001 is further configured to send the resource access result to the second process.

[0277] In one possible implementation, the first access request is used to request network access, the target descriptor includes a socket descriptor, the second access request also includes the address of the target network site, and the second access request is used to request access to the target network site; the processing unit 1002 is further used to execute the second access request according to the socket descriptor to obtain the access result of the target network site.

[0278] In one possible implementation, the processing unit 1002 is further configured to allocate a channel identifier pair to the target descriptor, the channel identifier pair including a first channel identifier and a second channel identifier, the channel identifier pair being used for data transmission between the first process and the target application, and the socket descriptor having a corresponding relationship with the channel identifier pair; the transceiver unit 1001 is further configured to send the first channel identifier to the second process.

[0279] In one possible implementation, the first access request is used to request to open a target file, the target descriptor includes a target file descriptor, and the second access request is used to request access to the target file; the processing unit 1002 is further used to execute the second access request according to the target file descriptor to obtain the access result of the target file.

[0280] In one possible implementation, the processing unit 1002 is further configured to establish a listener for the proxy descriptor; the transceiver unit 1001 is further configured to acquire a message sent by the listener, the message being used to indicate that the proxy descriptor is closed; the processing unit 1002 is further configured to close the target descriptor corresponding to the proxy descriptor according to the message.

[0281] In one possible implementation, the processing unit 1002 is further configured to establish a listener for the socket descriptor; the transceiver unit 1001 is further configured to acquire a message sent by the listener, the message indicating that the socket descriptor is closed; the processing unit 1002 is further configured to close the proxy descriptor corresponding to the socket descriptor according to the message.

[0282] In one possible implementation, the access request includes information about the target application; the processing unit 1002 is further configured to perform permission verification on the access request based on the information about the target application.

[0283] In one possible implementation, the access request further includes a third channel identifier, which is used to indicate a data transmission channel; the transceiver unit 1001 is also used to send the access result to the second process through the data transmission channel corresponding to the third channel identifier.

[0284] In one possible implementation, the first access request and the second access request further include a thread identifier corresponding to the target application; the processing unit 1002 is further configured to establish a correspondence between the third channel identifier and the thread identifier according to the first access request; the processing unit 1002 is further configured to determine the third channel identifier according to the thread identifier in the second access request; the transceiver unit 1001 is further configured to send the resource access result to the second process through the data transmission channel corresponding to the third channel identifier.

[0285] In another possible embodiment, the transceiver unit 1001 is used to acquire an access request from a target application running in a second process, the second process not having permission to execute the access request; the processing unit 1002 is used to send the access request to a first process, the first process having permission to execute the access request; the transceiver unit 1001 is also used to receive a proxy descriptor sent by the first process, the proxy descriptor being used to access system resources; the transceiver unit 1001 is also used to send the proxy descriptor to the target application.

[0286] In one possible implementation, the transceiver unit 1001 is further configured to: acquire a second access request from the target application, the second access request including the proxy descriptor, the second access request being used to request access to system resources; send the second access request to the first process; the second process receiving the resource access result sent by the first process; and the second process sending the resource access result to the target application.

[0287] In one possible implementation, the first access request is used to request network access, the second access request further includes the address of the target network site, the second access request is used to request access to the target network site, and the resource access result includes the access result of the target network site.

[0288] In one possible implementation, the proxy descriptor includes a first channel identifier for data transmission between the first process and the target application.

[0289] In one possible implementation, the first access request is used to request opening a target file, the target descriptor includes a target file descriptor, the second access request is used to request access to the target file, and the resource access result includes the access result of the target file.

[0290] In one possible implementation, the processing unit 1002 is further configured to create a channel identifier pair according to the access request, the channel identifier pair including a third channel identifier and a fourth channel identifier, the channel identifier pair being used for data transmission between the first process and the second process; the processing unit 1002 is further configured to add the third channel identifier to the access request; the transceiver unit 1001 is further configured to send an access request with the added third channel identifier to the first process.

[0291] In one possible implementation, the processing unit 1002 is further configured to add information of the target application to the access request; the transceiver unit 1001 is further configured to send an access request with the added information of the target application to the first process.

[0292] The access control method provided in this application embodiment can be specifically executed by a chip in a terminal. This chip includes a processing unit and a communication unit. The processing unit can be, for example, a processor, and the communication unit can be, for example, an input / output interface, pins, or circuits. The processing unit can execute computer execution instructions stored in a storage unit, causing the chip in the server to execute the aforementioned... Figures 1 to 10 The access control method described in the illustrated embodiment. Optionally, the storage unit is an on-chip storage unit, such as a register or cache. Alternatively, the storage unit can be an off-chip storage unit within the wireless access device, such as a read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, such as random access memory (RAM).

[0293] Reference Figure 11 This application also provides a computer program product in some embodiments, wherein the above-mentioned Figure 3 The disclosed method can be implemented as computer program instructions encoded in a machine-readable format on a computer-readable storage medium or on other non-transitory media or articles of art.

[0294] Figure 11 A conceptual partial view of an example computer program product arranged according to at least some of the embodiments shown herein is illustrated schematically. The example computer program product includes a computer program for executing computer processes on a computing device.

[0295] In one embodiment, computer program product 1100 is provided using signal bearer medium 1101. Signal bearer medium 1101 may include one or more program instructions 1102, which, when executed by one or more processors, can provide the above-mentioned... Figure 2 The described function or part of the function. Therefore, for example, refer to... Figure 3 In the embodiment shown, one or more features of steps 301-306 can be provided by one or more instructions associated with the signal carrying medium 1101. Furthermore, Figure 11 The program instruction 1102 in the document also describes example instructions.

[0296] In some examples, the signal carrying medium 1101 may include a computer-readable medium 1103, such as, but not limited to, a hard disk drive, a compact disc (CD), a digital video disc (DVD), a digital magnetic tape, a memory, ROM, or RAM, etc.

[0297] In some embodiments, the signal carrying medium 1101 may include a computer-recordable medium 1104, such as, but not limited to, a memory, a read / write (R / W) CD, a R / W DVD, etc. In some embodiments, the signal carrying medium 1101 may include a communication medium 1105, such as, but not limited to, digital and / or analog communication media (e.g., fiber optic cables, waveguides, wired communication links, wireless communication links, etc.). Therefore, for example, the signal carrying medium 1101 may be transmitted by a wireless form of communication medium 1105 (e.g., a wireless communication medium conforming to the IEEE 802.11 standard or other transmission protocols).

[0298] One or more program instructions 1102 may be, for example, computer-executable instructions or logical implementation instructions. In some examples, the computing device may be configured to provide various operations, functions, or actions in response to one or more program instructions 1102 conveyed to the computing device via a computer-readable medium 1103, a computer-recordable medium 1104, and / or a communication medium 1105.

[0299] It should be understood that the arrangements described herein are for illustrative purposes only. Therefore, those skilled in the art will understand that other arrangements and other elements (e.g., machines, interfaces, functions, sequences, and functional groups, etc.) can be used instead, and some elements may be omitted depending on the desired outcome. Furthermore, many of the described elements are functional entities that can be implemented as discrete or distributed components, or in any suitable combination and location with other components.

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

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

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

[0303] 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.

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

Claims

1. An access control method, characterized in that, include: The first process receives a first access request sent by the second process. The first access request comes from the target application running in the second process. The first process is the host process, and the second process is the isolated process. The second process does not have the permission to execute the first access request. The first process executes the first access request and obtains a target descriptor for accessing system resources; The first process allocates a proxy descriptor to the target descriptor. The target descriptor and the proxy descriptor have a corresponding relationship. The proxy descriptor is used to enable the first process to find the uniquely corresponding target descriptor. The first process sends the proxy descriptor to the second process, so that the second process can request the first process to access the system resources corresponding to the target descriptor based on the proxy descriptor; The first process accesses the system resources and returns the corresponding resource access results to the second process.

2. The method according to claim 1, characterized in that, The first process accesses the system resources and returns the corresponding resource access result to the second process, including: The first process receives a second access request sent by the second process. The second access request includes the proxy descriptor and is used to request access to system resources. The first process acquires the target descriptor corresponding to the proxy descriptor; The first process executes the second access request based on the target descriptor and obtains the resource access result; The first process sends the resource access result to the second process.

3. The method according to claim 2, characterized in that, The first access request is used to request network access, the target descriptor includes a socket descriptor, and the second access request also includes the address of the target network site, and the second access request is used to request access to the target network site; The first process executes the second access request based on the target descriptor and obtains the resource access result, including: The first process executes the second access request based on the socket descriptor and obtains the access result of the target network site.

4. The method according to claim 3, characterized in that, The first process allocates a proxy descriptor for the target descriptor, including: The first process allocates a channel identifier pair to the target descriptor. The channel identifier pair includes a first channel identifier and a second channel identifier. The channel identifier pair is used for data transmission between the first process and the target application. The socket descriptor has a corresponding relationship with the channel identifier pair. The first process sends the proxy descriptor to the second process, including: The first process sends the first channel identifier to the second process.

5. The method according to claim 2, characterized in that, The first access request is used to request to open the target file, the target descriptor includes a target file descriptor, and the second access request is used to request access to the target file; The first process executes the second access request based on the target descriptor and obtains the resource access result, including: The first process executes the second access request based on the target file descriptor and obtains the access result of the target file.

6. The method according to any one of claims 2-5, characterized in that, The method further includes: The first process establishes a listener for the proxy descriptor; The first process acquires a message sent by the listener, the message indicating that the proxy descriptor is closed; The first process closes the target descriptor corresponding to the proxy descriptor according to the message.

7. The method according to claim 3, characterized in that, The first process establishes a listener for the socket descriptor; The first process acquires a message sent by the listener, the message indicating that the socket descriptor is closed; The first process closes the proxy descriptor corresponding to the socket descriptor according to the message.

8. The method according to any one of claims 1-5, characterized in that, The access request includes information about the target application; The method further includes: The first process performs permission verification on the access request based on the information of the target application.

9. The method according to claim 2, characterized in that, The first access request also includes a third channel identifier, which is used to indicate a data transmission channel; The first process sends the access result to the second process, including: The first process sends the access result to the second process through the data transmission channel corresponding to the third channel identifier.

10. The method according to claim 9, characterized in that, The first access request also includes the thread identifier corresponding to the target application; The method further includes: The first process establishes a correspondence between the third channel identifier and the thread identifier based on the first access request; The first process sends the resource access result to the second process, including: The first process determines the third channel identifier based on the thread identifier in the second access request; The first process sends the resource access result to the second process through the data transmission channel corresponding to the third channel identifier.

11. An access control method, characterized in that, include: The second process receives a first access request from the target application, which runs within the second process, but the second process does not have permission to execute the access request. The second process sends the first access request to the first process. The first process has the permission to execute the first access request. The first process is the host process, and the second process is the isolated process. The second process receives a proxy descriptor sent by the first process. The proxy descriptor is used to access system resources. The proxy descriptor is allocated by the first process based on the target descriptor of the system resources, and the target descriptor and the proxy descriptor have a corresponding relationship. The second process sends the proxy descriptor to the target application; The second process obtains a second access request from the target application, the second access request including the proxy descriptor, and the second access request is used to request access to system resources; The second process sends the second access request to the first process; The second process receives the resource access results sent by the first process; The second process sends the resource access result to the target application.

12. The method according to claim 11, characterized in that, The first access request is used to request network access, the second access request also includes the address of the target network site, the second access request is used to request access to the target network site, and the resource access result includes the access result of the target network site.

13. The method according to claim 11 or 12, characterized in that, The proxy descriptor includes a first channel identifier, which is used for data transmission between the first process and the target application.

14. The method according to claim 11 or 12, characterized in that, The first access request is used to request to open the target file, the target descriptor includes a target file descriptor, the second access request is used to request access to the target file, and the resource access result includes the access result of the target file.

15. The method according to claim 11 or 12, characterized in that, The method further includes: The second process creates a channel identifier pair based on the access request. The channel identifier pair includes a third channel identifier and a fourth channel identifier. The channel identifier pair is used for data transmission between the first process and the second process. The second process adds the third channel identifier to the access request; The second process sends an access request to the first process with the third channel identifier added.

16. The method according to claim 11 or 12, characterized in that, The method further includes: The second process adds the target application's information to the access request; The second process sends an access request to the first process, which includes information about the target application.

17. A terminal, characterized in that, It includes a memory and a processor; the memory stores code, and the processor is configured to execute the code, wherein when the code is executed, the terminal performs the method as described in any one of claims 1 to 16.

18. A computer-readable storage medium, characterized in that, It includes computer-readable instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 16.

19. A computer program product, characterized in that, Includes computer-readable instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 16.

Images