Path matching based access control method, system, device and product

Abstract

The application discloses a path matching-based access control method, system, device and product, including: receiving a user access request, determining a target access path and an application operation permission based on the user access request; based on pre-configured role policy information, obtaining a target role corresponding to the user and a permission subset of the target role; traversing the permission subset of the target role, if there is a target path rule corresponding to the target access path in the permission subset, comparing the user operation permission and the application operation permission of the target path rule, and determining an access control result according to the comparison result. The explicit mapping relationship makes the role constraint relationship more explicit, so that the user configurable role and operation permission can be intuitively obtained, and on this basis, the system resources are safely identified based on the path rule, thereby avoiding the situation that the system resources cannot be identified due to the non-supporting of the extended attribute, guaranteeing the access control effect and improving the generation efficiency of the control result.

Description

Technical Field

[0001] This application relates to the field of access control technology, specifically to an access control method, system, device, and product based on path matching. Background Technology

[0002] Among existing access control technologies, role-based access control (RBAC) can associate permissions with roles, allowing users to indirectly obtain permissions through roles. This effectively simplifies permission management while ensuring the information security and data privacy of the operating system.

[0003] Specifically, existing RBAC implementations typically form a security context based on "user:role:type:level (i.e., user:role:type:level)", and add this security context to the extended attributes of system resources as an identifier for the system resources, so as to implement access control for files / directories based on this identifier.

[0004] However, when the file system does not support extended attributes, system resources cannot be identified in the above manner, which in turn affects access control to files / directories. Summary of the Invention

[0005] In view of the above-mentioned defects or deficiencies in the existing technology, it is desirable to provide an access control method, system, device and product based on path matching. This method adopts explicit mapping relationship to make role constraint relationship clearer, so as to intuitively obtain the user's configurable roles and operation permissions. On this basis, system resources are security identified based on path rules, thereby avoiding the situation that system resources cannot be identified due to lack of support for extended attributes, ensuring access control effect and improving the efficiency of control result generation.

[0006] In a first aspect, the present invention provides an access control method based on path matching, the method comprising: Receive user access requests, determine the target access path and request operation permissions based on the user access requests; Based on pre-configured role policy information, obtain the target role corresponding to the user and the permission subset of the target role; wherein, the role policy information includes at least the mapping relationship between users, roles and permissions; the permission subset includes at least one path rule, each path rule corresponds to an access path that allows user operation and user operation permissions; Iterate through the permission subset of the target role. If a target path rule corresponding to the target access path exists in the permission subset, compare the user operation permission with the requested operation permission of the target path rule, and determine the access control result based on the comparison result.

[0007] In one possible implementation, the access control result is determined based on the comparison result, including: If the comparison result indicates that the user's operation permissions for the target path rule match the requested operation permissions, then the access control result is determined to be "access allowed".

[0008] In one possible implementation, the role policy information also includes the user's role transition rules. The access control results are determined based on the comparison results, including: If the comparison result indicates that the user's operation permissions under the target path rule do not match the requested operation permissions, then the user's role conversion rule will be used to determine whether the user has a convertible role. If the user has a switchable role, update the user's target role and the target role's permission subset, and determine the access control result based on the updated permission subset; otherwise, determine the access control result as access denied.

[0009] In one possible implementation, if no target path rule corresponding to the target access path exists in the permission subset, the method further includes: Update the target access path to the access path of the parent node corresponding to the target access path, and traverse the permission subset of the target role based on the updated target access path.

[0010] In one possible implementation, if any access path that allows user operation corresponds to multiple user operation permissions, the multiple user operation permissions are sorted according to the order of their configuration time, and the last user operation permission is determined as the user operation permission corresponding to the access path.

[0011] In one possible implementation, role strategy information includes multiple sets of configuration relationships, and the configuration process for role strategy information includes: For any set of configuration relationships, complete the corresponding configuration based on a preset text format; the configuration relationships include at least: the mapping relationship between users and roles, the mapping relationship between users, roles and permissions, the mapping relationship between roles and permission subsets, the corresponding operation permissions of permission subsets, role conversion rules, and role constraint rules.

[0012] In one possible implementation, the method further includes configuring the mapping relationship between users, roles, and permissions: For any role to be configured, determine whether there are role constraint rules for the role. If there are, determine whether the role constraint rules are violated, and complete the configuration if there are no violations.

[0013] Secondly, a path-matching-based access control system is provided, which includes: The first processing module is used to receive user access requests, determine the target access path and request operation permissions based on the user access requests. The acquisition module is used to acquire the target role corresponding to the user and the permission subset of the target role based on the pre-configured role policy information; wherein, the role policy information includes at least the mapping relationship between users, roles and permissions; the permission subset includes at least one path rule, and each path rule corresponds to an access path that allows users to operate and user operation permissions; The second processing module is used to traverse the permission subset of the target role. If there is a target path rule corresponding to the target access path in the permission subset, the user operation permission and the requested operation permission of the target path rule are compared, and the access control result is determined based on the comparison result.

[0014] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the method of any one of the first aspects above.

[0015] Fourthly, a computer program product is provided, which contains instructions that, when the instructions are executed, execute any of the methods described in the first aspect above.

[0016] Fifthly, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the program, when executed by a processor, implements the method of any one of the first aspects above.

[0017] Compared to the current method of adding security context to the extended attributes of files / processes to identify resources, the path-matching-based access control method, system, device, and product provided in this application identify system resources based on path rules (i.e., corresponding to "user operation permissions + access path"). This eliminates the need to consider whether the file system type of the system resource supports extended attributes, avoiding situations where system resources cannot be identified due to lack of extended attributes, thus ensuring the effectiveness of access control. Secondly, the use of explicit mapping relationships makes role constraints clearer. When a user access request is received, the user's configurable roles and operation permissions can be intuitively obtained based on the pre-configured mapping relationships (i.e., the mapping relationship between users, roles, and permissions) without spending a lot of time, thereby improving the efficiency of generating control results. Attached Figure Description

[0018] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart illustrating an access control method based on path matching provided in an embodiment of this application. Figure 2 This is a schematic diagram of the process for configuring role policy information provided in an embodiment of this application; Figure 3 This is a schematic diagram of the process for checking based on role constraint rules provided in an embodiment of this application; Figure 4 This is a flowchart illustrating the policy update operation provided in an embodiment of this application; Figure 5 This is another flowchart illustrating the path-matching-based access control method provided in this application embodiment; Figure 6 This is a block diagram of a path-matching-based access control system 600 provided in an embodiment of this application; Figure 7 This is a schematic diagram of the architecture of the RBAC access control system based on path matching provided in the embodiments of this application; Figure 8 This is the top-level data flow graph of RBAC access control based on path matching provided in the embodiments of this application; Figure 9 This is a Layer 0 data flow graph of RBAC access control based on path matching provided in the embodiments of this application; Figure 10 This is a schematic diagram of path rule storage based on a linked list provided in an embodiment of this application; Figure 11 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0019] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0020] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. The present application will now be described in detail with reference to the accompanying drawings and embodiments. Furthermore, the term "and / or" in this document is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The terms "first" and "second," etc., in the specification and claims of the embodiments of this application are used to distinguish different objects, not to describe a specific order of objects.

[0021] Existing Linux security mechanisms are generally based on Mandatory Access Control (MAC), such as Security-Enhanced Linux (SELinux), Application Armor (AppArmor), Simplified Mandatory Access Control Kernel (Smack), and TOMOYO.

[0022] Specifically, SELinux is a MAC mechanism centered on Type Enforcement (TE). Its RBAC implementation typically configures security contexts for users, processes, files, and directories in the system. When a user / process accesses a file / directory, it obtains the security context of the user / process and the file / directory, and determines whether the user / process has access rights to the file / directory based on the built-in access control policy. The security context is composed of "user:role:category:security level", and the role field is used to implement role control.

[0023] However, the aforementioned resource identification method based on security tags requires adding a security context to the extended attributes of each file / process to achieve resource identification. For file systems that do not support extended attributes, resource identification cannot be achieved, thus affecting the access control effect. Furthermore, configuring security contexts is also a time-consuming and labor-intensive process. Secondly, when defining access control rules for the aforementioned RBAC application, role constraint rules typically use an implicit definition method to limit the scope of user-configurable roles, failing to intuitively reflect the constraint relationships between roles and reducing the efficiency of access control result generation to some extent.

[0024] Therefore, the unstable effect of existing resource identification and the difficulty in understanding role policy information have become problems that urgently need to be solved.

[0025] To address this, this application provides an access control method based on path matching. This method uses path rules of "user operation permissions + access path" to identify system resources, avoiding the situation where system resources cannot be identified due to lack of support for extended attributes. Secondly, it adopts intuitive explicit role constraint rules, making role constraint relationships clearer and configuration simpler, further improving usability.

[0026] In one possible implementation, Figure 1 This is a flowchart illustrating an access control method based on path matching provided in an embodiment of this application, such as... Figure 1As shown, the method specifically includes the following steps: Step S101: Receive user access request, determine the target access path and request operation permissions based on user access request.

[0027] For example, upon receiving a user access request, the absolute path can be resolved using the Virtual File System (VFS) in the Linux kernel to convert the string representing the target access path of the user access request into an accessible, in-memory file object.

[0028] Step S102: Based on the pre-configured role policy information, obtain the target role corresponding to the user and the permission subset of the target role.

[0029] In one possible implementation, the role policy information includes multiple sets of configuration relationships, which at least include: the mapping relationship between users and roles, the mapping relationship between users, roles and permissions, the mapping relationship between roles and permission subsets, the corresponding operation permissions of the permission subsets, role conversion rules, and role constraint rules.

[0030] For example, for any set of configuration relationships, the corresponding configuration can be completed based on a preset text format to obtain role strategy information.

[0031] In one example, when the configuration relationship represents the mapping between users and roles, the default text format is: <Username>:<User ID>:<Role Name 1>,<Role Name 2>,... For example, if the configuration file is: testuser:1000:user_role,base_role, it means that the user testuser with user ID 1000 has two roles: user_role and base_role; that is, the user testuser has a mapping relationship with the two roles user_role and base_role respectively.

[0032] In another example, when the configuration relationship represents the mapping between roles and subsets of permissions, the default text format is: <Character Name>:<Character Identifier>:<Permission Subset 1>,<Permission Subset 2>,... For example, if the configuration file is: user_role:1:home_perm,bin_perm,proc_perm, then the user_role role with role identifier 1 has all the permission configurations corresponding to the permission subsets of home_perm, bin_perm, and proc_perm; that is, the user_role role has a mapping relationship with the permission subsets of home_perm, bin_perm, and proc_perm respectively.

[0033] In another example, when configuring relationships to represent corresponding operation permissions for a subset of permissions, the default text format is: <[Permission Name]> <Access control permissions>:<path> For example, the configuration file example is as follows: [passwd_set_permission] rw-: / etc / passwd rw-: / etc / shadow rx: / bin / passwd This indicates that the passwd_set_permission permission subset has read and write permissions for / etc / passwd and / etc / shadow, and read and execute permissions for / bin / passwd.

[0034] In another example, when configuring relationship representation role transition rules, the default text format is: <Source Role>:<Path>:<Target Role> For example, if the configuration file is set to user_role: / bin / passwd:user_passwd_role, then the user_role role can use user_passwd_role to re-verify access permissions when the user_role fails to access the / bin / passwd file.

[0035] In another example, when configuring relationship-representation role constraint rules, the default text format is: <Constraint Rule Name>: <Role 1>, <Role 2>, ...: <Maximum Number of Roles that Can Coexist> For example, if the configuration file is security_const:sys_role,aud_role,sec_role,net_role:1, it means that the role constraint rule security_const defines that the four roles sys_role,aud_role,sec_role, and net_role cannot coexist.

[0036] Correspondingly, in the process of configuring the mapping relationship between users, roles and permissions, for any role to be configured, it is also necessary to determine whether there are role constraint rules for the role to be configured. If there are, it is determined whether the role constraint rules are violated, and the configuration is completed if there are no violations.

[0037] The text-formatted configuration file provided in this embodiment reduces the difficulty of understanding and maintenance costs for administrators.

[0038] Based on the pre-configured role policy information, the permission subset includes at least one path rule. Each path rule corresponds to an access path that allows user operation and the user's operation permission; that is, each path rule is defined as a permission, and a permission is used to represent which files / directories a user has corresponding operation permissions on in the system. Correspondingly, the set of all permissions in the system is defined as the permission set, and the permission set consisting of a portion of the permissions in the permission set is defined as the permission subset.

[0039] In one possible implementation, the target role corresponding to the user identifier and the permission subset corresponding to the target role can be obtained by querying role policy information. It should be noted that when a user identifier corresponds to multiple roles, the user's default role is determined as the target role, such as the role configured first.

[0040] For example, you can first query the mapping relationship between users and roles (i.e., the user-role mapping table) to obtain the target role corresponding to the user identifier, and then query the mapping relationship between roles and permission subsets (i.e., the role-permission subset mapping table) to obtain the permission subset corresponding to the target role.

[0041] Step S103: Traverse the permission subset of the target role. If there is a target path rule corresponding to the target access path in the permission subset, compare the user operation permission and the requested operation permission of the target path rule, and determine the access control result based on the comparison result.

[0042] In one possible implementation, after obtaining the permission subset through the above step S102, the permission subset can be traversed to determine whether there is a target path rule corresponding to the target access path in the permission subset (that is, the access path of the target path rule is the target access path).

[0043] For example, if a target path rule corresponding to the target access path exists in the permission subset, then the user operation permission in the target path rule is compared with the request operation permission.

[0044] For example, the comparison result can be obtained by performing bitwise operations on the user operation permissions and requested operation permissions in the target path rules.

[0045] Correspondingly, if the comparison result indicates that the user's operation permissions for the target path rule match the requested operation permissions, then the access control result is determined to be "access allowed".

[0046] Optionally, if the comparison result indicates that the user's operation permissions under the target path rule do not match the requested operation permissions, then the user's role conversion rules in the role policy information are used to determine whether the user has a convertible role, and the access control result is determined based on the existence of a convertible role.

[0047] For example, if the role conversion rule indicates that a user has a convertible role, then the user's target role and the target role's permission subset are updated, and the access control result is determined based on the updated permission subset; otherwise, the access control result is determined to be access denied.

[0048] For example, if a user has a convertible role, the mapping relationship between users and roles (i.e., the user-role mapping table) can be queried to determine whether the user is associated with this role. If associated, the target role is updated to the associated role (i.e., the convertible role), and the mapping relationship between roles and permission subsets (i.e., the role-permission subset mapping table) is queried to obtain the permission subset corresponding to the updated target role.

[0049] Correspondingly, the updated permission subset is traversed to determine whether there is a target path rule corresponding to the target access path in the permission subset, and then the access control result is determined based on the comparison result of the user operation permission and the requested operation permission of the target path rule. The process of determining the access control result is similar to the aforementioned step S103, and will not be described in detail here.

[0050] For example, if there is no target path rule corresponding to the target access path in the permission subset, the target access path is updated to the access path of the parent node corresponding to the target access path, and the permission subset of the target role is traversed based on the updated target access path; the traversal step is similar to the steps mentioned above, and will not be described in detail here.

[0051] In another embodiment of this application, a specific configuration method for role strategy information is also provided.

[0052] In one possible implementation, the configuration process generally includes the following steps: S1, Create a character; S2, create permissions and configure path rules; S3, Associated Role; S4, associated user; S5, strategy loading.

[0053] For example, Figure 2 This is a flowchart illustrating the configuration of role policy information provided in an embodiment of this application, such as... Figure 2 As shown, the specific steps include: Step S201: Determine the configuration type.

[0054] Step S202: Select the configuration tool according to the configuration type.

[0055] Correspondingly, if the configuration type is role management (i.e., the configuration relationship is a mapping relationship between users and roles), then select the role management tool and execute step S2031; if the configuration type is permission subset management (i.e., the configuration relationship is a mapping relationship between roles and permission subsets), then select the permission subset management tool and execute step S2032; if the configuration type is role association configuration (i.e., the configuration relationship is a mapping relationship between users, roles, and permissions), then select the role configuration tool and execute step S2033; if the configuration type is permission subset permission configuration (i.e., the configuration relationship is the corresponding operation permissions of permission subsets), then select the permission subset permission configuration tool and execute step S2034; if the configuration type is role conversion rule configuration (i.e., the configuration relationship is role conversion rules), then select the role conversion rule configuration tool and execute step S2035; if the configuration type is role constraint rule configuration (i.e., the configuration relationship is role constraint rules), then select the role constraint rule configuration tool and execute step S2036.

[0056] Step S2031: Create / delete a role.

[0057] Step S2032: Create / delete a subset of permissions.

[0058] Step S2033: Configure the user-role-permission subset association relationship.

[0059] Step S2034: Configure a subset of permissions.

[0060] Step S2035: Configure role conversion rules.

[0061] Step S2036: Configure role constraint rules.

[0062] Step S2041: Write the character configuration file.

[0063] Step S2042: Write the permission subset configuration file.

[0064] Step S2043: Determine whether the role to be configured has role constraint rules.

[0065] Correspondingly, if it exists, then proceed to step S205; otherwise, proceed to step S206.

[0066] Step S2044: Write the permission subset permission configuration file.

[0067] Step S2045: Write the role conversion rule configuration file.

[0068] Step S2046: Write the role constraint rule configuration file.

[0069] Step S205: Determine whether the role constraint rules are violated.

[0070] Correspondingly, if no violation occurs, step S206 is executed.

[0071] Step S206: Save the configuration.

[0072] Step S207: Write to the configuration file.

[0073] Specifically, Figure 3 This is a flowchart illustrating the role constraint rule-based inspection process provided in an embodiment of this application, such as... Figure 3 As shown, the process includes the following steps: Step S301: Obtain the role to be configured.

[0074] Step S302: Query role constraint rules.

[0075] Step S303: Determine whether there are any constraint rules.

[0076] Correspondingly, if it exists, then step S3041 is executed; otherwise, step S3042 is executed.

[0077] Step S3041: Obtain the maximum number of constrained roles that can coexist.

[0078] Step S3042: Save the configuration directly.

[0079] Step S305: Query the number of constrained roles that the user has configured.

[0080] Step S306: Determine whether the number of constrained roles configured by the user is less than the maximum number of constrained roles that can coexist.

[0081] Correspondingly, if so, proceed to step S3042; otherwise, proceed to step S307.

[0082] Step S307: Generate error information.

[0083] Step S308, configuration failed.

[0084] Step S309, configuration successful.

[0085] In this embodiment, the role-based constraint rule consists of "rule name + role list + number of coexisting roles". A role constraint rule can be quickly located by the role name. When associating user roles and allocating role levels, the "role list + number of coexisting roles" can be used to determine whether there is a constraint relationship between the target assigned / inherited role.

[0086] Based on this, the explicit constraint method applied in this embodiment can describe the coexistence relationship between roles and has the following technical effects: First, by explicitly defining the constraint relationship, it directly indicates whether there is a constraint relationship between roles; second, by using intuitive role constraint rules, the complexity of configuring role constraint rules is reduced; third, when modifying role constraint rules, there is no need to recompile the strategy.

[0087] In one possible implementation, the role policy information is updated when a policy update signal is received.

[0088] For example, policy updates can be achieved through operations such as parsing configuration files and loading policies; the configuration file parsing and loading process generally includes the following steps: S1 retrieves the configuration file content line by line; S2, parses the configuration file according to the configuration file format; S3, store the parsed content into the corresponding data structure; S4, after completing the parsing, loads the data into memory.

[0089] Specifically, Figure 4 This is a flowchart illustrating the policy update operation provided in an embodiment of this application, as shown below. Figure 4 As shown, the process includes the following steps: Step S401: Receive the policy update signal.

[0090] Step S402: Traverse all configuration files.

[0091] Step S403: Traverse the contents of the configuration file.

[0092] Step S404: Configuration file parsing complete.

[0093] Step S405: Load into memory and save.

[0094] Step S406: Replace the old strategy.

[0095] Step S407: Release the old strategy.

[0096] In another embodiment of this application, a specific method for defining path rules is also provided.

[0097] In one possible implementation, different permissions can have different operation permissions for the same access path, but the same permission subset cannot simultaneously have two permissions with the same access path but different operation permissions; that is, the same role cannot have two permission subsets with the same access path but different operation permissions.

[0098] For example, if any access path that allows user operation corresponds to multiple user operation permissions, the multiple user operation permissions are sorted according to the configuration time order, and the last user operation permission is determined as the user operation permission corresponding to the access path.

[0099] In one example, when any subset of permissions contains the following three permission configurations: rw- / etc / passwd rw- / etc / shadow rx / bin / passwd These represent read and write permissions for the / etc / passwd file, read and write permissions for the / etc / shadow file, and read and execute permissions for the / bin / passwd file, respectively.

[0100] Based on this, these three permissions can be categorized as a subset of password configuration permissions: passwd_set_permission, so that this subset of permissions can be associated with a role, that is, the role will have password configuration permissions.

[0101] In the above permission configuration, there is a conflict between the permission "rw- / etc / passwd" and the permission "rx / etc / passwd". In this case, the later configured permission "rx / etc / passwd" can override the permission "rw- / etc / passwd".

[0102] In this embodiment, path rules are formed based on "user operation permissions + access path," which has the following advantages compared to the existing identification method based on extended attributes: First, the path identifier is obtained through the kernel VFS layer and does not depend on whether the file system supports extended attribute functionality; Second, it is applicable to all file system types that support path access, including but not limited to ext4, xfs, fat32, ntfs, etc.; Third, it does not require adding additional security labels to file system resources, reducing the intrusion into the file system; Fourth, it supports configuring path rules for directories, so that all resources under a directory are access controlled based on the directory's path rules; In addition, when configuring policies, the path rules are easy to understand and configure, reducing the difficulty and learning cost for users and maintenance personnel to understand the rules.

[0103] In another embodiment of this application, another path-matching-based access control method is also provided.

[0104] In one possible implementation, Figure 5 This is another flowchart illustrating the path-matching-based access control method provided in this application embodiment, such as... Figure 5 As shown, the process specifically includes the following steps: Step S501: Obtain the user identifier.

[0105] Step S502: The VFS layer resolves the absolute path.

[0106] Step S503: Query the user-role mapping table.

[0107] Step S504: Obtain the user's default role.

[0108] Step S505: Query the role-permission subset mapping table.

[0109] Step S506: Obtain a subset of all permissions for the role.

[0110] Step S507: Traverse the permission subset.

[0111] Step S508: Query path rules in the permission subset.

[0112] Step S509: Determine whether a path rule has been found.

[0113] Correspondingly, if so, step S50101 is executed; otherwise, step S50102 is executed.

[0114] Step S50101: Obtain access control permission bits.

[0115] Step S50102: Obtain the absolute path of the parent node.

[0116] Step S5011: Perform bitwise operations with the requested permissions.

[0117] Step S5012: Determine if the permissions match.

[0118] Correspondingly, if a match is found, step S50131 is executed; otherwise, step S50132 is executed.

[0119] Step S50131: Access granted.

[0120] Step S50132, permission verification failed.

[0121] Step S5014: Query the role conversion rule table.

[0122] Step S5015: Determine if there is a convertible role.

[0123] Correspondingly, if it exists, then proceed to step S5016; otherwise, proceed to step S5018.

[0124] Step S5016: Check the user-role mapping table.

[0125] Step S5017: Determine whether the user is associated with this role.

[0126] Correspondingly, if there is a correlation, step S505 is executed; otherwise, step S5018 is executed.

[0127] Step S5018, Access denied.

[0128] In another embodiment of this application, a path-matching-based access control system 600 is also provided.

[0129] In one possible implementation, Figure 6 This is a block diagram of a path-matching-based access control system 600 provided in an embodiment of this application, as shown below. Figure 6 As shown, the path-matching-based access control system 600 includes a first processing module 601, an acquisition module 602, and a second processing module 603.

[0130] For example, the first processing module 601 is used to receive a user access request, determine the target access path and request operation permissions based on the user access request; The acquisition module 602 is used to acquire the target role corresponding to the user and the permission subset of the target role based on the pre-configured role policy information; wherein, the role policy information includes at least the mapping relationship between users, roles and permissions; the permission subset includes at least one path rule, and each path rule corresponds to an access path that allows users to operate and user operation permissions; The second processing module 603 is used to traverse the permission subset of the target role, and if there is a target path rule corresponding to the target access path in the permission subset, compare the user operation permission and the requested operation permission of the target path rule, and determine the access control result based on the comparison result.

[0131] In another embodiment of this application, a system architecture corresponding to the path-matching-based access control method is also provided.

[0132] For example, Figure 7 This is a schematic diagram of the architecture of the RBAC access control system based on path matching provided in the embodiments of this application, as shown below. Figure 7 As shown, the system architecture is divided into a user layer and a kernel layer. System users initiate access requests to files through applications in the user layer, and these access requests are transmitted to the RBAC access control check module in the kernel layer.

[0133] Specifically, on the user side, administrators can use the RBAC policy configuration toolset to form an RBAC policy configuration file set. The RBAC policy configuration toolset includes role management, permission subset management, role association configuration, permission subset permission configuration, role conversion rule configuration, and role constraint rule configuration. The RBAC policy configuration file set includes user-role mapping relationship, role conversion rule, effective permission subset, role-permission subset mapping relationship, role constraint rule, historical roles, permission subset permissions, effective roles, and historical permission subset.

[0134] Specifically, on the kernel layer side, the RBAC policy parsing module reads the configuration relationships in the RBAC policy configuration file set and the policy update messages pushed by the administrator user, and transmits them to the RBAC policy configuration file set in the kernel layer for path parsing, file system processing, and kernel callback function processing, respectively. The processing results are then transmitted to the RBAC access control checking module, which is used to determine the permission decision result of the access request (i.e., allow / deny). The RBAC policy configuration file set includes a user-role mapping table, a role-permission subset mapping table, a role constraint rule storage table, a permission subset permission storage table, and a role transition rule storage table.

[0135] Correspondingly, Figure 8 This is the top-level data flow graph of RBAC access control based on path matching provided in the embodiments of this application, such as... Figure 8 As shown, the RBAC access control module receives policy update / policy view commands input by the administrator user and sends the configured policy to the system terminal; secondly, the RBAC access control module receives the user identifier and the system file to be accessed sent by the system user, and generates and returns the access result.

[0136] Correspondingly, Figure 9 This is a Layer 0 data flow graph of RBAC access control based on path matching provided in the embodiments of this application, such as... Figure 9 As shown, the administrator user sends policy configuration to the RBAC user-level policy configuration, and the RBAC user-level policy configuration sends the policy configuration to the user-level policy storage; the RBAC policy parser receives policy update / policy view commands sent by the administrator user, reads the user-level policy configuration, and transmits the parsed RBAC policy to the kernel-level policy storage; the RBAC access control check reads the kernel-level policy, receives the user identifier and accessed system file sent by the system user, and generates and returns the access result; among these, the RBAC policy parser is also used to send the parsed kernel-level policy configuration to the system terminal, and the kernel-level policy storage is used to read the kernel-level policy.

[0137] Based on the above data flow, when a system user initiates an access request, the access behavior can be checked through the RBAC access control inspection function provided by the RBAC mechanism. Secondly, administrator users can complete the RBAC policy configuration at the user level and load the user-level policy configuration into the kernel level by sending a policy update message through the RBAC policy parsing function. Administrator users can also output the RBAC policy loaded in the kernel level to the system terminal by sending a policy viewing message.

[0138] The following is a specific example of role-based access control based on path rules: User definitions: System administrator user, system security officer user, system auditor user, and regular user; Role definitions: User management role, system management role, audit management role, basic role; Permission definitions: Password management permission, system time management permission, audit log viewing permission, basic permissions; The user-role-permission mapping relationship satisfies the following Table 1: Table 1 User-Role-Permission Mapping Relationship

[0139] In one example of an access request: Request: The system administrator user is requested to view the / etc / passwd file; User role: System administrator role; Permission verification process: Obtain user-associated roles: Obtain system management roles based on the system administrator user.

[0140] Obtain role-related permissions: Obtain system time management permissions based on the system management role.

[0141] Parse the access path: Parse the path / etc / passwd to obtain the corresponding path hash value.

[0142] Access path-based query permissions: Search within the system time management permissions based on the path hash value.

[0143] Permission verification: No permissions were found for this file.

[0144] Verification result returned: Access denied.

[0145] Result: Access request denied.

[0146] In another example of an access request: Request: The system auditor user is requested to modify the / var / log / auth file; User role: Audit management role; Permission verification process: Obtain user-associated roles: Obtain audit management roles based on system auditor users.

[0147] Obtain role-related permissions: Obtain access to audit logs based on the audit management role.

[0148] Parse the access path: Parse the path / var / log / auth to obtain the corresponding path hash value.

[0149] Access path-based query permissions: Search within the audit log viewing permissions based on the path hash value.

[0150] Perform permission verification: compare the found read permissions with the requested write permissions.

[0151] Verification result returned: Access denied.

[0152] Result: Access request denied.

[0153] In another example of an access request: Request: The system security administrator user needs to view user information in / etc / passwd; User roles: User management roles; Permission verification process: Obtain user-associated roles: Obtain user management roles based on system security officer users.

[0154] Obtain role-related permissions: Obtain password management permissions based on the user's management role.

[0155] Parse the access path: Parse the path / etc / passwd to obtain the corresponding path hash value.

[0156] Access path-based query permissions: Search within password management permissions based on the path hash value.

[0157] Perform permission verification: compare the found read and write permissions with the requested read permissions.

[0158] Verification result returned: Access is allowed.

[0159] Result: Access request allowed.

[0160] In another embodiment of this application, other forms of path rules are also provided.

[0161] In one possible implementation, the path is split and stored according to directory nodes, with each directory node storing data information of its parent directory and subdirectories / subfiles; that is, the path rules are stored based on a prefix tree.

[0162] For example, the path / home / testuser / testfile is split into a three-level structure for storage: the first level stores / home, and its subdirectories / subfiles store / testuser; the second level stores / testuser, its parent directory stores / home, and its subdirectories / subfiles store / testfile; the third level stores / testfile, its parent directory stores / testuser, and its subdirectories / subfiles store empty nodes.

[0163] In another possible implementation, the path rules are stored in the form of a bitmap, and a corresponding bit being 1 indicates that the path rule corresponding to that bit is in effect; that is, permission mapping based on a bitmap matrix.

[0164] For example, when the four path rules correspond to the following storage locations in the bitmap: path rule 1 is stored in bit 0, and the expression for path rule 1 being set is "0001"; path rule 2 is stored in bit 1, and the expression for path rule 2 being set is "0010"; path rule 3 is stored in bit 2, and the expression for path rule 3 being set is "0100"; and path rule 4 is stored in bit 3, and the expression for path rule 4 being set is "1000"; then the mapping relationship between their roles and path rules can be represented as shown in Table 2 below: Table 2. Permission Mapping Based on Bitmap Matrix

[0165] Based on this, it can be clearly stated that role 1 has the permissions corresponding to path rules 1 and 3; role 2 has the permissions corresponding to path rule 2; and role 3 has the permissions corresponding to path rules 1 and 4.

[0166] Another possible implementation is to store path rules based on a linked list structure, utilizing the continuity of the linked list to store path rules under the same permission; that is, permission management based on linked list aggregation.

[0167] For example, Figure 10 This is a schematic diagram of path rule storage based on linked lists provided in an embodiment of this application, such as... Figure 10 As shown, in the path rule storage data structure based on linked lists, the head node (node ​​1) stores path rule 1, node 2 stores path rule 2, node 3 stores path rule 3, node 4 stores path rule 4, and so on.

[0168] The following is for reference. Figure 11 , Figure 11 A schematic diagram of a communication device suitable for implementing embodiments of this application is shown, such as... Figure 11As shown, the communication device 1100 includes a central processing unit (CPU) 1101, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1102 or a program loaded from a storage section 1108 into a random access memory (RAM) 1103. The RAM 1103 also stores various programs and data required for the system's operating instructions. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via a bus 1104. An input / output (I / O) interface 1105 is also connected to the bus 1104.

[0169] The following components are connected to the input / output (I / O) interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a LAN card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to the input / output (I / O) interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on the drive 1110 as needed so that computer programs read from them can be installed into the storage section 1108 as needed.

[0170] Specifically, according to embodiments of this application, the flowchart above refers to... Figures 1-5 The described process can be implemented as a computer software program. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program contains program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit (CPU) 1101, it performs the functions defined in the system of this application.

[0171] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium compatible with computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0172] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operational instructions of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two connected blocks may actually be executed substantially in parallel, or they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified functions or operational instructions, or using a combination of dedicated hardware and computer instructions.

[0173] The units or modules described in the embodiments of this application can be implemented in software or hardware. The described units or modules can also be housed in a processor; for example, a processor may be described as including a semantic extraction unit, a weight allocation unit, and a determination unit. The names of these units or modules do not necessarily constitute a limitation on the unit or module itself.

[0174] On the other hand, this application also provides a computer-readable storage medium, which may be included in the communication device described in the above embodiments, or may exist independently and not assembled into the communication device. The aforementioned computer-readable storage medium stores one or more programs that, when used by one or more processors, execute the methods described in this application. For example, it may execute... Figures 1-5 The steps of the method shown are as follows.

[0175] This application provides a computer program product including instructions that, when executed, cause the method described in this application to be performed. For example, it can execute... Figures 1-5 The steps of the method shown are as follows.

[0176] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of disclosure in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the foregoing disclosed concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. An access control method based on path matching, characterized in that, The method includes: Receive user access requests, determine the target access path and request operation permissions based on the user access requests; Based on pre-configured role policy information, the target role corresponding to the user and the permission subset of the target role are obtained; wherein, the role policy information includes at least the mapping relationship between users, roles and permissions, and also includes the user's role conversion rules; the permission subset includes at least one path rule, and each path rule corresponds to an access path that allows the user to operate and the user's operation permission. Traverse the permission subset of the target role to determine whether there is a target path rule corresponding to the target access path in the permission subset; if there is a target path rule corresponding to the target access path in the permission subset, compare the user operation permission of the target path rule with the application operation permission; If the comparison result indicates that the user operation permission of the target path rule matches the requested operation permission, then the access control result is determined to be allowed access; If the comparison result indicates that the user's operation permissions under the target path rule do not match the requested operation permissions, then the user is determined to have a convertible role according to the role conversion rule; if the user has a convertible role, the user's target role and the permission subset of the target role are updated, and the access control result is determined based on the updated permission subset; otherwise, the access control result is determined to be access denied. If no target path rule corresponding to the target access path exists in the permission subset, the method further includes: updating the target access path to the access path of the parent node corresponding to the target access path, and traversing the permission subset of the target role based on the updated target access path.

2. The access control method based on path matching according to claim 1, characterized in that, If any access path that allows user operation corresponds to multiple user operation permissions, the multiple user operation permissions are sorted according to the configuration time order, and the last user operation permission is determined as the user operation permission corresponding to the access path.

3. The access control method based on path matching according to claim 1, characterized in that, The role strategy information includes multiple sets of configuration relationships, and the configuration process of the role strategy information includes: For any set of configuration relationships, the corresponding configuration is completed based on a preset text format; the configuration relationships include at least: the mapping relationship between users and roles, the mapping relationship between users, roles and permissions, the mapping relationship between roles and permission subsets, the corresponding operation permissions of the permission subsets, role conversion rules, and role constraint rules.

4. The access control method based on path matching according to claim 3, characterized in that, The method further includes the following steps in configuring the mapping relationship between users, roles, and permissions: For any role to be configured, determine whether the role has role constraint rules. If it does, determine whether the role constraint rules are violated, and complete the configuration if they are not violated.

5. An access control system based on path matching, characterized in that, The system includes: The first processing module is used to receive user access requests, determine the target access path and request operation permissions based on the user access requests. The acquisition module is used to acquire the target role corresponding to the user and the permission subset of the target role based on pre-configured role policy information; wherein, the role policy information includes at least the mapping relationship between users, roles and permissions, and also includes the user's role conversion rules; the permission subset includes at least one path rule, and each path rule corresponds to an access path that allows the user to operate and the user's operation permission. The second processing module is used to traverse the permission subset of the target role to determine whether there is a target path rule corresponding to the target access path in the permission subset; if there is a target path rule corresponding to the target access path in the permission subset, the user operation permission of the target path rule is compared with the application operation permission. If the comparison result indicates that the user operation permission of the target path rule matches the requested operation permission, then the access control result is determined to be allowed access; If the comparison result indicates that the user's operation permissions under the target path rule do not match the requested operation permissions, then the user is determined to have a convertible role according to the role conversion rule; if the user has a convertible role, the user's target role and the permission subset of the target role are updated, and the access control result is determined based on the updated permission subset; otherwise, the access control result is determined to be access denied. If there is no target path rule corresponding to the target access path in the permission subset, the second processing module is further configured to: update the target access path to the access path of the parent node corresponding to the target access path, and traverse the permission subset of the target role based on the updated target access path.

6. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 1-4.

7. A computer program product, characterized in that, The computer program product includes instructions that, when executed, cause the method as described in any one of claims 1-4 to be implemented.

Images