Capability type-based compile-time system resource access control method, system and readable storage medium

Abstract

The embodiment of the application discloses a kind of based on ability type's compiling period system resource access control method, system and readable storage medium.The method comprises: receiving the permission declaration file submitted by application;Based on the permission declaration file, generate the ability type set corresponding to authorized system resource in type system;Load system API function signature carrying implicit ability type parameter;In the type checking context of the ability type set, compile application source code, make the call to unauthorized system API be rejected at compiling period, generate the native machine code containing authorized resource access instruction sequence.The technical scheme provided in the application integrates resource permission into compiler type system, makes unauthorized system API call become type error and be rejected at compiling period, and there is no overreach call path on the structure of generated native machine code, so that the security attack surface caused by overreach call is eliminated from the root.

Description

Technical Field

[0001] This application relates to operating system security and compiler type system technology, and in particular to a compile-time system resource access control method, system, and readable storage medium based on capability type. Background Technology

[0002] In the realm of operating system resource access, it is necessary to control application access to system resources (such as the file system, network, GPU, camera, etc.) to ensure system security. Currently, Android uses a Manifest file to declare permissions in XML to implement resource access control. This approach allows applications to access all system APIs during the compilation phase, resulting in a binary file containing all system call paths. At runtime, however, it enforces verification of application permission requests. The main problem with this approach is that even if an application is not granted access to a certain type of resource, its binary file still retains the corresponding unauthorized call paths, becoming a potential attack surface. Attackers can exploit vulnerabilities to bypass permission restrictions and cause system security risks. Summary of the Invention

[0003] This application provides a compile-time system resource access control method, system, and computer-readable storage medium based on capability types, which solves the problem that existing resource access control schemes force permission verification at runtime, resulting in application binary files retaining unauthorized call paths and creating security attack surfaces.

[0004] On one hand, embodiments of this application provide a compile-time system resource access control method based on capability types, the method comprising: Receive permission declaration files submitted by the application; Based on the permission declaration file, a set of capability types corresponding to authorized system resources is generated in the type system, wherein unauthorized system resources have no corresponding capability type definition; Load the system API function signature carrying an implicit capability type parameter, wherein the implicit capability type parameter corresponds to the capability type in the capability type set; The application source code is compiled in the type checking context of the set of capability types, so that calls to unauthorized system APIs are denied at compile time, generating native machine code containing a sequence of authorized resource access instructions.

[0005] Preferably, the method further includes: The resource path types in the application code are identified at compile time, including static resource paths and dynamic resource paths; Perform compile-time constraint compliance checks on static resource paths and insert runtime constraint check instructions on dynamic resource paths.

[0006] Preferably, the capability type is parameterized at least according to the dimensions of resource category, operation type, and resource scope.

[0007] Preferably, the generated native machine code does not contain system call instructions targeting unauthorized resources, function pointers referencing unauthorized system APIs or indirect call targets, or instruction sequences that can be reinterpreted as invoking unauthorized operations.

[0008] On the other hand, embodiments of this application also provide a readable storage medium on which a computer program is stored, which, when executed by a processor, implements the aforementioned method steps.

[0009] Furthermore, embodiments of this application also provide a compile-time system resource access control system based on capability types. This system includes: a permission declaration receiving module, a capability type generation module, an API signature providing module, a compilation verification module, and a native machine code generation module, wherein: The permission declaration receiving module is used to receive permission declaration files submitted by the application; The capability type generation module is used to generate a set of capability types corresponding to the authorized system resources in the compiler's type system based on the permission declaration file, wherein unauthorized resources have no corresponding type definition; The API signature providing module is used to load system API function signatures that carry implicit capability type parameters; The compilation verification module is used to compile the application source code in the type checking context of the capability type set, so that calls to unauthorized system APIs are rejected at compile time; The native machine code generation module is used to generate native machine code containing a sequence of authorized resource access instructions.

[0010] Preferably, the capability type generated by the capability type generation module is parameterized at least according to the dimensions of resource category, operation type, and resource range.

[0011] Preferably, the system further includes a path verification module and a path execution module, wherein: The path verification module is used to identify the resource path type in the application code during the compilation phase; The path execution module is used to perform compile-time constraint compliance checks on static resource paths and insert runtime constraint check instructions on dynamic resource paths.

[0012] Preferably, the native machine code generated by the native machine code generation module does not contain direct system call instructions targeting unauthorized resources, function pointers or indirect call targets referencing unauthorized system APIs, or instruction sequences that can be reinterpreted as invoking unauthorized operations.

[0013] The technical solution provided in this application integrates resource permissions into the compiler type system, making unauthorized system API calls directly become type errors and rejected at compile time. The generated native machine code structure does not have unauthorized call paths, eliminating the security attack surface caused by unauthorized calls from the root. At the same time, it does not require additional runtime permission verification overhead, thus balancing system security and running efficiency. Attached Figure Description

[0014] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 A flowchart illustrating the compile-time system resource access control method based on capability type provided in this application embodiment; Figure 2 This is a schematic diagram of the path constraint checking process provided in an embodiment of this application; Figure 3 This is a structural block diagram of a compile-time system resource access control system based on capability type, provided in an embodiment of this application. Detailed Implementation

[0015] The technical solution of this application will be clearly and completely described below with reference to the concepts in the embodiments of this application. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0016] As mentioned earlier, existing operating system resource access control schemes primarily rely on runtime verification mechanisms. Taking Android's Manifest permission declaration as an example, application developers declare the required permissions in an XML-formatted Manifest file. During the application compilation phase, the compiler does not perform permission-related verification for system API calls. Only at runtime does the system kernel or application framework layer verify whether the current application has been granted the corresponding permissions. Under this mechanism, the application's binary file will contain a sequence of all called system API instructions, regardless of whether the permissions corresponding to that API are ultimately granted. For example, an application may only request permission to read files in its own directory, but the compiled binary file may still contain API call instructions to read sensitive system directories (such as / etc / passwd). Attackers can trigger these instructions through reverse engineering, vulnerability exploitation, etc., to attempt to bypass permission restrictions.

[0017] Besides Android, similar issues exist with iOS's Entitlements solution, FreeBSD's Capsicum capability system, and Java's SecurityManager: iOS Entitlements rely on kernel runtime mandatory verification, and the application binary still retains all system call paths; although Capsicum introduces capability-mode processes, runtime mandatory verification increases system overhead and programming complexity, and does not prevent unauthorized calls at the compilation stage; Java SecurityManager's stack-based permission checks not only incur runtime overhead but were also removed in Java 17; Rust's unsafe mechanism only implements binary allow / deny operations and cannot manage resource access at the module level; although WASM Imports checks import dependencies at link time, the output is bytecode rather than native machine code, which cannot adapt to the runtime scenarios of native applications.

[0018] In summary, the core problem with existing technologies is that they do not deeply integrate resource permissions with compiler type systems, making it impossible to directly block unauthorized system API calls during the compilation phase. This results in unauthorized call paths remaining in application binary files, creating a security attack surface. Furthermore, runtime permission verification mechanisms either increase system overhead or have complex programming models, making it difficult to balance security and ease of use.

[0019] To address the problems existing in the prior art, this application provides a compile-time system resource access control method based on capability types. The main purpose is to transform application permission declarations into capability types in the compiler type system, making system API calls dependent on the corresponding capability type as implicit parameters. Unauthorized APIs cannot be compiled due to the lack of corresponding capability type definitions, ultimately generating native machine code without unauthorized call paths. See also... Figure 1 The figure illustrates a flowchart of a compile-time system resource access control method based on capability types according to an embodiment of this application. The method includes the following steps: Step S11: The compiler receives the permission declaration file submitted by the application; The compiler, acting as the execution entity, first reads the permission declaration file (such as the JSON-formatted app.manifest.json) provided by the application developer. This file explicitly declares the system resources the application needs to authorize, including resource categories (such as file system (fs), network (net), GPU, camera, etc.), operation types (such as read, write, HTTPS access, etc.), resource scope (such as file path, network domain name, etc.), and authorization indicators. For example, in the permission declaration file of a note-taking application, it declares that reading and writing files under the / data / my-note-app / directory is allowed, access to the HTTPS interface of api.my-notes.com is allowed, access to the GPU and camera is prohibited, and only the text embedding capability of the AI ​​module is allowed. The output of this step is the parsed structured data of the permission declaration, providing input for the subsequent generation of capability types.

[0020] Step S12: The compiler generates a set of capability types based on the permission declaration file; The compiler takes the structured permission declaration data output by S11 as input and generates a corresponding set of capability types in its own type system. Capability types are internal type identifiers used by the compiler to characterize whether an application is authorized to access a certain type of resource. Their naming rules correspond one-to-one with the resource category, operation type, and resource scope in the permission declaration. Unauthorized resources do not generate corresponding capability type definitions. Specifically, for resources declared as authorized, the compiler generates a generic capability type containing the resource category, operation type, and resource scope. For example, for `fs.read` with the authorized path " / data / my-note-app / **", the generated type is `Cap_FsRead = CapabilityToken`.<FileSystem, Read," / data / my-note-app / **"> This process registers the type in the current compilation context; for resources declared as prohibited (such as gpu: false), the corresponding Cap_Gpu type is not defined in the compilation context. The output of this step is the set of capability types registered in the compilation context, providing input for subsequent API type validation.

[0021] Step S13: The compiler loads the system API function signatures carrying implicit capability type parameters; The compiler reads system API libraries provided by the operating system (such as sys / fs.ts and sys / net.ts). The function signatures of these APIs contain implicit capability type parameters, which are not visible to application developers and are only used as a basis for compiler type checking. For example, the readFile function signature in the system library contains the implicit parameter __cap: Cap_FsRead, the writeFile function contains __cap: Cap_FsWrite, and the gpuCompute function contains __cap: Cap_Gpu. The output of this step is a set of system API type signatures with implicit capability type parameters, serving as the benchmark for compile-time type checking. Its input depends on the predefined system API libraries and is associated with the capability type set generated by S12 (the implicit parameters of the APIs correspond to specific capability types).

[0022] Step S14: The compiler compiles the application source code in the context of capability type and performs type checking; The compiler takes the set of capability types generated in S12 and the API type signatures loaded in S13 as input to compile the application source code. During compilation, the compiler checks whether each system API call has a corresponding capability type definition: if the application calls a system API and the implicit capability type parameter of that API is registered in the compilation context (i.e., the application has authorized the resource), the type check passes; if the implicit capability type parameter is not defined (i.e., the application has not authorized the resource), the compiler determines it as a type error, directly refuses to compile, and prompts that the corresponding capability type is missing. For example, when the application calls readFile(" / data / my-note-app / notes.json"), the type check passes because Cap_FsRead is registered; when it calls gpuCompute(), a compilation error is triggered because Cap_Gpu is not defined. In addition, for static resource paths (such as string literals), the compiler also checks whether the path matches the resource scope in the permission declaration. For example, when calling readFile(" / etc / passwd"), a type error is triggered because the path does not match " / data / my-note-app / **". The output of this step is either the application intermediate code that has passed type validation, or a compilation error message indicating that the validation failed.

[0023] Step S15: The compiler generates native machine code without any unauthorized resource access instructions; The compiler takes the valid intermediate code output from S14 as input and compiles it into native machine code. Since unauthorized API calls are blocked in S14, the generated native machine code only contains system API call instructions corresponding to authorized resources; it contains no unauthorized system call paths, function pointers, or instruction sequences that could be reinterpreted as unauthorized operations. For example, applications that restrict access to the GPU will have no gpuCompute-related instruction sequences in their native machine code, structurally eliminating the possibility of unauthorized calls. The output of this step is the final native machine code file, which can be run directly on the target operating system.

[0024] The technical solution of this application converts permission declarations into capability types in the compiler type system, directly blocking unauthorized system API calls from the compilation stage. Compared with the prior art, it has the following core effects: (1) It can effectively eliminate the security attack surface: There are no unauthorized system call paths in the generated native machine code structure. Attackers cannot trigger unauthorized operations through reverse engineering or vulnerability exploitation, which improves system security from the root. For example, even if existing Android applications are not granted camera permissions, their binary still retain the requestCamera call instruction. However, in this solution, this instruction cannot be compiled due to the lack of Cap_Camera type definition. There is no such instruction sequence in the native machine code, which completely eliminates the possibility of unauthorized camera calls. (2) No runtime permission verification overhead, effectively saving resource consumption: The runtime verification of existing technologies (such as Android permission checks, Capsicum capability modes, etc.) will increase the system running overhead. However, this solution puts the permission verification in advance to the compilation stage. There is no need for additional permission check logic at runtime, which reduces system resource consumption and improves application running efficiency. (3) The programming model is simplified: application developers do not need to modify the code to adapt the permission verification logic. They only need to write standard system API call code. The capability type verification is automatically completed by the compiler. Compared with Capsicum and other solutions that require developers to adapt capability patterns, the programming complexity is greatly reduced.

[0025] The aforementioned technical solutions have addressed the technical problems existing in the prior art. To address the potential need for more refined resource path verification in these solutions in real-world scenarios, this application also proposes a series of optimized technical solutions. For example, this application may consider adopting differentiated verification strategies for static and dynamic paths to further improve the accuracy of resource access control. See also... Figure 2 The diagram illustrates a flowchart of the optimization technical solution, specifically the path constraint check process. The specific implementation steps include: Step S21: The compiler identifies the resource path type in the application code during the compilation phase; if it is a static path, proceed to step S22; if it is a dynamic path, proceed to step S23. As the execution entity, the compiler can add additional path type identification logic during the S14 compilation process to distinguish between static resource paths (string literals) and dynamic resource paths (calculated strings) in system API calls. A static path refers to a path directly passed to the API in a fixed string format, such as `readFile(" / data / my-note-app / notes.json")`; a dynamic path refers to a path calculated using variables, expressions, etc., such as `readFile(userInput + ".json")`. The output of this step is API call information annotated with the path type, providing input for subsequent differential validation.

[0026] Step S22: The compiler performs compile-time constraint checks on the static paths; For the static paths identified in step S21, the compiler extracts the path strings and performs a matching and verification process with the resource scopes (such as file path patterns and network domain names) declared in the capability types generated in S12. For example, if the resource scope corresponding to the capability type Cap_FsRead is " / data / my-note-app / **", the compiler verifies whether the static path conforms to this pattern: if it does, the verification passes; otherwise, a type error is triggered. This step requires no runtime code insertion, achieving zero runtime overhead. Its inputs are the path type annotation information from S21 and the capability type resource scope from S12, and its output is the static path verification result, which is integrated into the compilation and verification process in S14.

[0027] Step S23: The compiler inserts runtime constraint verification instructions into the dynamic path; For the dynamic paths identified in step S21, since the compiler cannot determine the final path value at compile time, a runtime path verification instruction is automatically inserted when generating intermediate code. The logic of this instruction is as follows: before calling the system API, it verifies whether the calculated dynamic path matches the resource range corresponding to the capability type. If they do not match, a system trap is triggered to terminate the operation. For example, for `readFile(userInput + ".json")`, the compiler inserts the code `if(!pathMatches(computed_path, " / data / my-note-app / **")) trap()`, where the `pathMatches` function verifies whether the path conforms to the authorization mode. The output of this step is the intermediate code with the inserted runtime verification instruction, which serves as the input for generating native machine code in S15.

[0028] The optimized solution described above, building upon the basic approach, further enhances the precision of resource access control: for static paths, verification is performed directly at compile time, eliminating runtime overhead and ensuring application efficiency; for dynamic paths, only minimal runtime path comparison instructions are inserted, significantly reducing system overhead compared to the full runtime permission verification of existing technologies. Simultaneously, runtime verification of dynamic paths ensures that even if the path is dynamically calculated, it cannot exceed the authorized resource scope, further blocking unauthorized access vulnerabilities; while compile-time static path verification preemptively blocks obvious unauthorized path calls, reducing runtime security verification pressure. Overall, this optimized solution balances the efficiency of compile-time verification with the fallback effect of runtime verification, achieving comprehensive resource path control without significantly increasing system overhead.

[0029] The foregoing description details the method embodiments provided in this application. In fact, this application also provides corresponding system embodiments. See [link to relevant documentation]. Figure 3 The diagram illustrates the structural block diagram of a system embodiment. The compile-time system resource access control system U30 embodiment based on capability types of this application includes: a permission declaration receiving module U31, a capability type generation module U32, an API signature providing module U33, a compilation verification module U34, and a raw machine code generation module U35, wherein: the permission declaration receiving module U31 is used to receive permission declaration files submitted by applications; the capability type generation module U32 is used to generate a set of capability types corresponding to authorized system resources in the compiler's type system based on the permission declaration files, wherein unauthorized resources have no corresponding type definitions; the API signature providing module U33 is used to load system API function signatures carrying implicit capability type parameters; the compilation verification module U34 is used to compile application source code in the type checking context of the capability type set, so that calls to unauthorized system APIs are rejected at compile time; and the raw machine code generation module U35 is used to generate raw machine code containing a sequence of authorized resource access instructions.

[0030] Based on the same principle, the aforementioned system embodiment can also be optimized, with further modules added to the system. For example, the capability types generated by the aforementioned capability type generation module can be parameterized at least according to the dimensions of resource category, operation type, and resource scope. The native machine code generated by the aforementioned native machine code generation module U35 does not contain direct system call instructions targeting unauthorized resources, function pointers referencing unauthorized system APIs or indirect call targets, or instruction sequences that can be reinterpreted as invoking unauthorized operations. Furthermore, the aforementioned system can further add some functional components, such as a path verification module U36 and a path execution module U37, wherein: the path verification module U36 is used to identify resource path types in the application code during the compilation phase; the path execution module U37 is used to perform compile-time constraint compliance verification on static resource paths and insert runtime constraint verification instructions on dynamic resource paths. Both the aforementioned system embodiment and the further optimized technical functional modules can achieve the same technical effects as the aforementioned method embodiment; to avoid repetition, further details are omitted here.

[0031] Furthermore, the technical solution of this application can be formed on a computer-readable storage medium to form a computer program. The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

[0032] The embodiments of this application can achieve all the inventive objectives using the aforementioned software; therefore, the software portion has been primarily described. Those skilled in the art should understand that the embodiments of this application can be provided as an apparatus, system, or related computer program product. Therefore, this application can be implemented entirely in hardware, entirely in software, or in a combination of software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

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

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

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

[0036] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0037] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0038] Computer-readable media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0039] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0040] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A compile-time system resource access control method based on capability types, characterized in that, The method includes: Receive permission declaration files submitted by the application; Based on the permission declaration file, a set of capability types corresponding to authorized system resources is generated in the type system, wherein unauthorized system resources have no corresponding capability type definition; Load the system API function signature carrying an implicit capability type parameter, wherein the implicit capability type parameter corresponds to the capability type in the capability type set; The application source code is compiled in the type checking context of the set of capability types, so that calls to unauthorized system APIs are denied at compile time, generating native machine code containing a sequence of authorized resource access instructions.

2. The method according to claim 1, characterized in that, The method further includes: The resource path types in the application code are identified at compile time, including static resource paths and dynamic resource paths; Perform compile-time constraint compliance checks on static resource paths and insert runtime constraint check instructions on dynamic resource paths.

3. The method according to claim 1, characterized in that, The capability type is parameterized at least according to the dimensions of resource category, operation type, and resource scope.

4. The method according to claim 1, characterized in that, The generated native machine code does not contain system call instructions targeting unauthorized resources, function pointers or indirect call targets referencing unauthorized system APIs, or instruction sequences that can be reinterpreted as invoking unauthorized operations.

5. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 4.

6. A compile-time system resource access control system based on capability types, characterized in that, include: The module includes a permission declaration receiving module, a capability type generation module, an API signature providing module, a compilation and verification module, and a native machine code generation module, among which: The permission declaration receiving module is used to receive permission declaration files submitted by the application; The capability type generation module is used to generate a set of capability types corresponding to the authorized system resources in the compiler's type system based on the permission declaration file, wherein unauthorized resources have no corresponding type definition; The API signature providing module is used to load system API function signatures that carry implicit capability type parameters; The compilation verification module is used to compile the application source code in the type checking context of the capability type set, so that calls to unauthorized system APIs are rejected at compile time; The native machine code generation module is used to generate native machine code containing a sequence of authorized resource access instructions.

7. The system according to claim 6, characterized in that, The capability type generation module generates capability types that are parameterized at least according to the dimensions of resource category, operation type, and resource scope.

8. The system according to claim 6, characterized in that, The system also includes a path verification module and a path execution module, wherein: The path verification module is used to identify the resource path type in the application code during the compilation phase; The path execution module is used to perform compile-time constraint compliance checks on static resource paths and insert runtime constraint check instructions on dynamic resource paths.

9. The system according to claim 6, characterized in that, The native machine code generated by the native machine code generation module does not contain direct system call instructions targeting unauthorized resources, function pointers referencing unauthorized system APIs or indirect call targets, or instruction sequences that can be reinterpreted as invoking unauthorized operations.

Images