CN116702126A

CN116702126A - Application access control method and device, computing device and readable storage medium

Info

Publication number: CN116702126A
Application number: CN202310610617.4A
Authority: CN
Inventors: 蒋皓; 周鹏; 卢新友; 王现利; 张亚
Original assignee: Uniontech Software Technology Co Ltd
Current assignee: Uniontech Software Technology Co Ltd
Priority date: 2023-05-26
Filing date: 2023-05-26
Publication date: 2023-09-05

Abstract

The invention discloses an application access control method and device, a computing device and a readable storage medium, relates to the technical field of computing system access control, and can solve the technical problems of excessively complex and low fine granularity of the current forced access control. The application access control method comprises the following steps: responding to an access request of a subject application to a guest resource, and reading a strategy file which is set in advance, wherein the strategy file comprises a blacklist mode basic strategy module; judging whether the subject application and the object resource are in a blacklist or not according to the strategy file; and if the subject application and the object resource are not in the blacklist, allowing the subject application to access the object resource according to the authority given by the blacklist mode basic strategy module. According to the technical scheme, the blacklist mode basic strategy module is adopted, and only when the application needs to be protected, the strategy needs to be written, and the object can be independently controlled and protected.

Description

Application access control method and device, computing device and readable storage medium

Technical Field

The present invention relates to the field of computing system access control technology, and in particular, to an application access control method and apparatus, a computing device, and a readable storage medium.

Background

In Linux operating systems, the most basic protection for resources (files, devices, ipcs, etc.) in the system is access control. The access control supported in Linux includes both autonomous access control (DAC) and Mandatory Access Control (MAC). This document is primarily directed to mandatory access control. Two currently employed forced access control means are described below.

SELinux is a sub-module in a Linux Security Module (LSM) for realizing forced access control in a Linux system, and is one of forced access control modules in a Linux kernel. Under SELinux, all subjects and objects have a type tag associated with them. To access a certain object, the type of subject must have access rights to the type of object. The access rights of the type of subject to the type of object are determined by the security policy. While the security policy of SELinux follows the "whitelist" mechanism, only the operation showing "allow" in the security policy can succeed, otherwise the operation is refused. Thus, in a SELinux-enabled system, a process can only access the resources that the security policy allows it to access, and cannot access any other resources, regardless of the user to whom the process belongs (even the super user root). Based on this, in general, as long as a reasonable security policy is written for an application program, the application program can only access necessary resources required for its operation, and other resources cannot be accessed, so that the security of the application is enhanced and the destructiveness thereof is limited.

SELinux has the disadvantage of being overly complex and since SELinux is a whitelist mechanism, most applications must write, debug and modify their own SELinux policy if they want to use normally. This causes SELinux security policies to lag behind the application, resulting in SELinux often impeding the proper operation of the application when the user is running the application.

Apparmor (Application Armor ) is a path-based mandatory access control module that provides mandatory access control only for specially designated applications, controls the ability of applications to access files, directories and networks, and other processes all operate in uncontrolled states. Appormor will load appormor policy profiles for all applications into the kernel at system start-up, the profiles defining the permissions and capabilities of the applications, one profile for each appartus controlled by appormor, and the name of the profile being forcibly associated with the name and path of the application.

Apparmor effectively solves the complexity and ecological problems existing in SELinux: SELinux is a white list mechanism, so an application developer has to write a security policy to run normally, and appamor is a black list mechanism and can be used normally without applying the write policy, and only when the application needs to be protected, the write policy is needed, and the policy only takes effect on the application.

However, the use of Apparmor sacrifices the security of the system: 1. the operation object of appormer is a subject, does not play any role for an unknown application or an unconfigured application, and cannot protect an object resource alone, and appormer cannot play a role if it is intended to protect a certain system important file from being tampered with by the unknown application through forced access control. 2. Appamor does not support files, directories, networks, hardware, etc. resources, but does not support management of many ipc related resources, such as shared memory, message queues, semaphores, etc., as SELinux, for the fine granularity of the kind of resources and rights management.

Disclosure of Invention

To this end, the present invention provides an application access control method and apparatus, computing device, and readable storage medium in an effort to solve or at least alleviate at least one of the problems presented above.

According to a first aspect of the present invention, there is provided an application access control method for controlling access of a subject application to a guest resource, including: responding to an access request of a subject application to a guest resource, reading a strategy file which is set in advance, wherein the strategy file comprises a blacklist mode basic strategy module, the blacklist mode basic strategy module defines a blacklist of the subject application and the guest resource, and endows the subject application outside the blacklist with authority for accessing the guest resource outside the blacklist; judging whether the subject application and the object resource are in a blacklist or not according to the strategy file; and if the subject application and the object resource are not in the blacklist, allowing the subject application to access the object resource according to the authority given by the blacklist mode basic strategy module.

Optionally, the application access control method according to the present invention further includes: if any one or both of the subject application and the object resource are in the blacklist, inquiring the security policies of the subject application and the object resource in the policy file; allowing the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define access rights of the subject application to the guest resource; and if the security policies of the host application and the guest resource do not define the access authority of the host application to the guest resource, the host application is refused to access the guest resource.

Optionally, in the application access control method according to the present invention, the security policy of the guest resource includes one of the following: allowing any other application to access the guest resource; allowing the subject application to access the guest resource; the security policy applied by the principal comprises one of: allowing the subject application to access any other applications; the subject application is allowed to access the guest resource.

Optionally, in the application access control method according to the present invention, the blacklist mode base policy module is written based on a SELinux whitelist mechanism existing in the system, and in the blacklist mode base policy module: defining a blacklist of subject application and object resources through attribute policy statements; defining subject application and object resources included in the blacklist through a type attribute strategy statement; by allowing policy statements, subject applications outside of the blacklist are given access to guest resources outside of the blacklist.

Optionally, the application access control method according to the present invention further includes: in response to user input, the blacklist mode base policy module is offloaded to switch back to the SELinux whitelist mechanism of the kernel system.

According to a second aspect of the present invention, there is provided an application access control apparatus for controlling access of a subject application to a guest resource, comprising: the system comprises a reading module, a storage module and a storage module, wherein the reading module is used for responding to an access request of a subject application to a guest resource and reading a strategy file which is set in advance, the strategy file comprises a blacklist mode basic strategy module, the blacklist mode basic strategy module defines blacklists of the subject application and the guest resource, and the authority of the subject application outside the blacklist for accessing the guest resource outside the blacklist is given; the judging module is used for judging whether the subject application and the object resource are in a blacklist or not according to the strategy file; and the release module is used for allowing the subject application to access the object resource according to the authority given by the blacklist mode basic strategy module if the subject application and the object resource are not in the blacklist.

Optionally, the application access control device according to the present invention further includes: the query module is used for querying the security policies of the subject application and the object resource in the policy file if any one or both of the subject application and the object resource are in the blacklist; an access permission module, configured to permit the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define an access right of the subject application to the guest resource; and the rejecting module is used for rejecting the host application to access the object resource if the security policies of the host application and the object resource do not define the access authority of the host application to the object resource.

Optionally, in the application access control device according to the present invention, the security policy of the guest resource includes one of the following: allowing any other application to access the guest resource; allowing the subject application to access the guest resource; the security policy applied by the principal comprises one of: allowing the subject application to access any other applications; the subject application is allowed to access the guest resource.

According to a third aspect of the present invention there is provided a computing device comprising: at least one processor and a memory storing program instructions; the program instructions, when read and executed by the processor, cause the computing device to perform the application access control method as described above.

According to a fourth aspect of the present invention, there is provided a readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform an application access control method as described above.

According to the technical scheme, the blacklist mode basic strategy module is adopted, so that normal use can be realized without applying a write strategy, and only when an application needs to be protected, the write strategy is needed, and the strategy only takes effect on the application. In addition, the objects can be independently controlled and protected.

Drawings

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which set forth the various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to fall within the scope of the claimed subject matter. The above, as well as additional objects, features, and advantages of the present disclosure will become more apparent from the following detailed description when read in conjunction with the accompanying drawings. Like reference numerals generally refer to like parts or elements throughout the present disclosure.

FIG. 1 shows a schematic diagram of a blacklist mechanism of an embodiment of the present invention;

FIG. 2 illustrates the mechanism of action of a security policy written separately by a blacklist mechanism according to an embodiment of the invention;

FIG. 3 shows a schematic flow chart of an application access control method according to an embodiment of the invention;

FIG. 4 shows a schematic block diagram of an application access control device according to an embodiment of the present invention;

FIG. 5 shows a schematic diagram of a computing device according to one embodiment of the invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

Aiming at the defects in the background art, including excessively complex SELinux, insufficient safety of appamor and the like, the invention provides a design thought which can solve the defects, wherein the design thought comprises: 1. the embodiment of the invention is realized on the basis of SELinux and is realized by properly modifying the SELinux, so that the advantages of the SELinux are utilized. 2. The defect of SELinux can be solved by modifying SELinux into a blacklist mechanism, and the advantage of appormor is utilized.

The blacklist mechanism described above is directed to "whether or not to control", i.e., by default all subjects and objects are not controlled and protected, only subjects and objects that are added to the blacklist are controlled and protected. The access control mechanism generated by the design concept is different from Apparmor in that: a guest management and control function is added.

The above describes the overall design concept of the present invention. The following descriptions respectively apply: white list mechanism in mandatory access module such as SELinux, blacklist mechanism of the present invention, examples of application access control method and apparatus according to embodiments of the present invention.

It should be understood that SELinux and apammor are described herein as examples only to facilitate an understanding of the design concepts of the present invention by those skilled in the art. The technical scheme according to the embodiment of the invention can be realized on the basis of other forced access control modules, and can also be independently realized as the forced access control module in the kernel.

The whitelist mechanism in a mandatory access module such as SELinux is first described to facilitate understanding by those skilled in the art: when implementing the blacklist mechanism of the present invention on SELinux, the "blacklist mode base policy module" of the present invention is how to write. Similarly, the writing mechanism is also applicable to the following cases: the blacklist mechanism of the present invention is implemented solely as a mandatory access control module in the kernel.

On machines that turn on the mandatory access control module, all access controls may involve hosts, objects, operations and rule bases.

The subject and object refer to subject application and object resources in a single access process. Regarding guest resources, the prior art blacklist mechanism does not support the management and control of many inter-process communication related resources such as shared memory, message queues, semaphores, etc. However, according to the technical scheme of the invention, besides resources such as files, directories, networks, hardware and the like, access control over various resources including shared memory, message queues, semaphores and the like can be supported.

Rule base refers to the collection of all security policies, a file named policy.x (X is the version number of the rule base). One application corresponds to a set of security policies, which may be referred to as security policy modules, each of which contains three files (.te files,. If files,. Fc files). A number of such security policy modules are linked to the file policy x when loaded into the kernel.

The manner in which the security policy is written is described below.

In an access control module like SELinux, the object to which the security policy acts is not a specific certain file or process, but a tag, which is also called type (type). A label or type is understood to be an abstraction of a class of processes or files, each of which is labeled on the system. Processes or files with the same tag have the same security policy. Tag types are defined in the te file by type rules, such as: type security_t.

In this way, a type security_t is defined, so that a desired file or process, etc. can be tagged with the security_t, and which files are tagged with the tag is recorded in the fc file.

The key points of the white list mechanism are as follows: the security policy is defined by an allowed policy rule. Only operations allowed by the allowed (allowed) policy rules can be successfully performed. The format of the allowed (allowed) policy rules is as follows: allowSubjtObjt: class { OperateSet }.

Where obj_t is the tag of the object and subj_t is the tag of the subject. The tag of an object is generally referred to as a type (type), and the tag of a subject is generally referred to as a domain (domain). The domain is essentially a type, and in the art, labels of a subject and labels of an object are then differently referred to in order to distinguish between the subject and the object.

Class is a Class of objects, such as a general file (file), a directory (dir), a character device file (chr_file), a network interface (netif), a process itself (process), capability (capability), and the like. OperateSet is a specific operation such as open, read, write.

For example, the policy allowances pass_t shadow_t file { open read write } allows a subject process in the pass_t domain to read and write a guest file labeled shadow_t.

Under the whitelist mechanism, a domain's rights to all resources it needs to access do not require an rule of allowances to assign. An attribute (attribute) rule is provided to save the volume of the security policy and to improve the efficiency of writing the security policy. An attribute (attribute) rule may define an attribute (attribute), which may be understood as "a collection of types having a set of commonalities". A domain or object type may also be added to an attribute by a type attribute (typeattribute) rule.

Such as the following policy statement: attribute security _type; attribute security _domain; typeattribute shadow _t security_type; typeattribute security _t security_type; typeattribute passwd _t security_domain; typeattribute sysadm _t security_domain; the allowances security_domain security_type is file { open read write }.

In the above policy statement, an object attribute security_type and a subject attribute security_domain are defined by an attribute (attribute) policy statement, and security_t and shadow_t are added to the security_type by a type attribute (attribute) policy statement (or, security_t and shadow_t become members of the attribute security_type), and pass_t and sysadm_t are added to the security_domain (or, pass_t and sysadm_t become members of the attribute security_domain).

Then, by allowing (allow) policy statements to give security_domain read-write rights to security_type, it is equivalent to giving members of all security_domains read-write rights to members of all security_types. That is, this one allow policy statement is equivalent to the following four allow policy statements: allowances pass_t shadow_t file { open read write }; allowances pass wd_tstechnical_t, file { open read write }; allowssysadm_t shadow_t file { open read write }; allowssysadm_t security_t file { open read write }.

The above attribute (attribute) rule greatly enhances convenience in security policy development, and reduces the number of security policies (the more members of an attribute, the greater the benefit).

In the whitelist mechanism, the use of "- (minus)" in the subj_t and obj_t fields is also supported to exclude security policy assignments to subjects or objects of a certain set, in the following format: allowSubj { obj-except_obj }; allow { subj-except_subj } obj: class { OperateSet }; allow { subj-except_subj } { obj-except_obj } { class { OperateSet }.

Wherein, the allowable_subj is the subject to be excluded, and the allowable_obj is the object to be excluded. The subject (sub j and allowable_sub j) and the object (obj and allowable_obj) may be one attribute or may be a single type.

Format 1 is illustrated. For example, format 1 may specifically be: the allowDomain { file_type-secret_file_type }. This policy statement example uses two important attributes: domain and file_type. The attribute domain is defined as a set of all process domains on the system, that is, all process domains on the system add this attribute (added by the typeattribute statement above), and file_type is a set of all file types on the system, and all object file types on the system add this attribute. If the attribute secret_file_type is defined as the set of all confidential files on the system, { file_type-secret_file_type } is the set left after subtracting the intersection with secret_file_type from the set file_type, i.e. the set of all non-confidential files. The policy instance gives all process domains on the system access to all non-confidential files on the system. The principle of format 2 and format 3 is the same as this.

After writing the above policies in the. Te file, the. If file and the. Fc file are rewritten. Wherein the if file defines an interface that facilitates programming. The three files are then compiled together into a.pp module file. If the module is named xxx, then the three files are named xxx.te, xxx.if and xxx.fc, respectively, and the compiled. Pp file is named xxx.pp. After loading the xxx.pp file, the security policy defined in the te file starts to take effect. At this time, the related application has the authority given by the alloy policy in the xxx.

The principles of the blacklist mechanism of the present invention are described below. The blacklist mechanism of the present invention may be implemented on the basis of the policy mechanism supported by SELinux above. The core mechanism utilized by the present invention is attribute (attribute). Two attributes are first defined: attribute blacklist _type; attribute blacklist _domain. The blacklist_type attribute is an object blacklist, and the blacklist_domain is a subject blacklist. Initially, the two blacklists have no members.

Then, write an allow (allow) policy statement, giving all subject domains on the system except for the blacklist_domain member access to all guest types on the system except for the blacklist_type member. Rights are granted, for example, by: allow { domain-blacklist_domain } { file_type-blacklist_type }; allow { domain-blacklist-domain } { file_type-blacklist_type }; allow { domain-blacklist-domain } { file_type-blacklist_type }.

The above examples refer to only part of the source code, and the actual source code may cover all file types on the system, including files (files), directories (dir), sockets (socket_files), network interfaces (netif), etc. Where all_file_arms is a macro that defines all legal operations on a file. In addition to using all_file_arms, wild cards may also be used. The advantage of using wild cards is that no judgment of categories is required, and policy settings are simpler. The particular manner of setting can be selected as desired by those skilled in the art. all_dir_arms and all_pack_file_arms are the same.

Since both black lists are initially empty, by compiling the series of allowed policy statements (referred to as "black list mode base policy") described above and compiling them into security policy modules (referred to as "black list mode base policy modules"), it is equivalent to a module that has the right to give all subjects on the system access to all objects. At this time, if the blacklist mode basic policy module is loaded, the policy blacklist mode is started, and if the module is unloaded, the original policy whitelist mechanism is restored.

After filling the blacklist with a host application or guest resource by a type attribute (type) policy statement, after loading the "blacklist schema base policy module", all host domains of members on the system other than blacklist_domain have access to all guest types of members on the system other than blacklist_type. That is, the domain of the subject application that needs to be controlled and protected is added to the attribute blacklist_domain, and then the subject application is no longer authorized by the allowances rule in the blacklist schema underlying policy. Similarly, the type of the object resource to be controlled and protected is added into the attribute blacklist_type, so { domain-blacklist_domain } can not acquire the authority of accessing the object resource to be controlled and protected through the allowances in the blacklist mode basic strategy'.

Fig. 1 shows a schematic diagram of the blacklist mechanism of the present invention. As shown in fig. 1, adding app3_t to blacklist_domain, app3_t cannot access any member in file_type through "blacklist mode base policy" (top arrow line in the figure), as indicated by arrow line with "x"; the file3_t is added to the blacklist_type, and any member in domain cannot access the file3_t through the blacklist mode base policy.

In the above manner, all subject applications that join blacklist_domain are managed and guarded. If it is desired that these applications have access to the resources they need, security policies may be written separately for these applications so that these applications can only access the resources they own security policies allow access to. Similarly, all guest resources that join the blacklist_type are also guarded, however, specific process domains may be allowed to access them by way of writing security policies to them separately.

Fig. 2 shows the mechanism of action of this separately written security policy. Although app3_t cannot access the file2_t members of the file_type attribute through the "blacklist mode base policy" (uppermost arrow), it may be allowed to access file2_t by writing an allowances security policy for app3_t alone, as shown by the lowermost arrow line of fig. 2.

The above-described individual security policies may be written in the security module corresponding to the host application app3_t, in the security module corresponding to the guest resource file2_t, or in both modules. As described above, the security module corresponding to the host application and/or the security module corresponding to the guest resource is summarized together with the blacklist schema base policy module into a policy. When an application accesses a resource, the kernel queries the policy.x file to make a determination of access rights.

The following describes an application access control method proposed according to an embodiment of the present invention. The method is used for controlling the access of the host application to the guest resource and is executed by a system kernel. Fig. 3 shows a schematic flow chart of the application access control method. As shown in fig. 3, the method includes steps 310-330. The steps are described in detail below.

In step 310, in response to the subject application's access request to the guest resource, a policy file set in advance is read, the policy file including a blacklist mode base policy module. As described above, the blacklist mode base policy module defines a blacklist of subject applications and guest resources and gives subject applications outside of the blacklist access to guest resources outside of the blacklist.

In step 320, it is determined whether the subject application and the object resource are in the blacklist according to the policy file.

In step 330, if the subject application and the guest resource are not in the blacklist, the subject application is allowed to access the guest resource according to the authority given by the blacklist mode base policy module.

Further, the method shown in fig. 3 may further include: if any one or both of the subject application and the object resource are in the blacklist, inquiring the security policies of the subject application and the object resource in the policy file; allowing the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define access rights of the subject application to the guest resource; and if the security policies of the host application and the guest resource do not define the access authority of the host application to the guest resource, the host application is refused to access the guest resource.

Optionally, the security policy of the object comprises one of: allowing any other application to access the guest resource; the subject application is allowed to access the guest resource. The security policy applied by the principal comprises one of the following: allowing the subject application to access any other applications; the subject application is allowed to access the guest resource.

The first step in the white list mechanism currently in use in the system is to check the security policy of the host-guest resource itself. According to the blacklist mechanism of the present invention, it is first checked whether the host application a and the guest resource B are in the blacklist, and if so, the host application a and the guest resource B are checked for their own security policies. Herein, "in the blacklist" means that the subject application a is in the blacklist, the object resource B is not in the blacklist, or the subject application a is not in the blacklist, the object resource B is in the blacklist, or both the subject application a and the object resource B are in the blacklist. If in the black list, the subject application a is allowed to access the guest resource B only if the security policy of the subject application a and/or the guest resource B defines the access rights. The access rights refer to: the security policy of the subject application a defines that the subject application a is allowed to access other objects, or separately defines that the subject application a is allowed to access the object resource B; either the security policy of guest resource B defines that other applications are allowed to access guest resource B or the host application a is allowed to access guest resource B alone.

In addition, in the case of using appmor in the prior art, several modules implementing forced access control of the kernel are mutually exclusive and cannot coexist, if it is necessary to close appmor if further opening stricter forced access control, such as SELinux, is desired on a system in which appmor is enabled by default, then the policy written for appmor is discarded, resulting in great waste of policy resources. In addition, the switching between the two modes involves complex processes of changing the starting parameters, re-labeling the file, etc., which may cause the user to need too long waiting time, resulting in bad experience.

According to the technical scheme of the embodiment of the invention, if the original white name single control mode is to be switched, the original white list mechanism can be switched back by only unloading the strategy blacklist module of SELinux. The method may therefore further comprise: in response to user input, the blacklist mode base policy module is offloaded to switch back to the whitelist mechanism of the kernel system.

Therefore, the security policy under the white list mechanism written for the application added with the black list can still be used continuously, so that policy resources are reused, waste of policy resources is avoided, the switching cost is very low, only the configuration or policy of SELinux is required to be modified, and even a user cannot perceive the switching process.

In summary, the key point of the embodiment of the present invention is to create two attributes, blacklist_domain and blacklist_type, and write a "blacklist schema base policy": access rights are granted to all resources of members within the set { file_type-blacklist_type }. At the beginning, the two black lists are empty, and because all process domains on the system are members of domain and all file labels on the system are members of file_type, all processes have the authority to access all files on the system under the initial default condition. If it is desired to manage an application, only a security policy needs to be written separately for the application, and a domain of the application defined in the security policy of the application is added to the blacklist_domain. Thereafter, the application does not belong to a member of the set { domain-blacklist_domain }, and cannot obtain any rights to access members within the set { file_type-blacklist_type } through the "blacklist schema base policy". And managing and controlling the object resources.

In summary, according to the technical scheme of the embodiment of the invention, the blacklist basic policy module is adopted or the SELinux is transformed into the policy blacklist mechanism, so that the authority control fine granularity is finer, the object can be independently controlled and protected, and the advantage of the appamor control blacklist mechanism is possessed. Under the condition of transformation on the basis of SELiux, the cost of transformation is very low, and the transformation is only needed to write and add a 'blacklist mode basic strategy module', so that any modification on a SELinux kernel source code and an original security strategy is not needed.

An application access control apparatus according to an embodiment of the present invention is described below. The device is used for controlling the access of the host application to the guest resource and is positioned in the system kernel. Fig. 4 shows a schematic block diagram of the application access control device. As shown in fig. 4, the apparatus includes a reading module 410, a judging module 420, and a releasing module 430. The reading module 410 is configured to read, in response to an access request of the host application to the guest resource, a policy file set in advance, where the policy file includes a blacklist mode base policy module. The judging module 420 is configured to judge whether the subject application and the object resource are in the blacklist according to the policy file. The release module 430 is configured to allow the subject application to access the guest resource according to the authority given by the blacklist mode base policy module if the subject application and the guest resource are not in the blacklist.

Further, the apparatus shown in fig. 4 may further include a query module, configured to query the policy file for the security policies of each of the host application and the guest resource if either or both of the host application and the guest resource are in the blacklist; an access permission module, configured to permit the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define an access right of the subject application to the guest resource; and the rejecting module is used for rejecting the host application to access the object resource if the security policies of the host application and the object resource do not define the access authority of the host application to the object resource.

In a non-detailed part of the application access control device according to an embodiment of the invention, reference is also made to the above detailed description of the method embodiments.

The method of the present invention may be performed in a computing device. The computing device may be any device having storage and computing capabilities, and may be implemented, for example, as a server, a workstation, or the like, or may be implemented as a personal configured computer such as a desktop computer, a notebook computer, or may be implemented as a terminal device such as a mobile phone, a tablet computer, an intelligent wearable device, or an internet of things device, but is not limited thereto.

FIG. 5 shows a schematic diagram of a computing device according to one embodiment of the invention. It should be noted that the computing device shown in fig. 5 is only an example, and in practice, the computing device used to implement the method of the present invention may be any type of device, and the hardware configuration of the computing device may be the same as the computing device shown in fig. 5 or may be different from the computing device shown in fig. 5. The hardware components of the computing device used in practice to implement the methods of the present invention may be added or subtracted from the hardware components of the computing device shown in fig. 5. The embodiment of the invention does not limit the specific hardware configuration situation of the computing equipment.

As shown in fig. 5, the apparatus may include: processor 510, memory 520, input/output interface 530, communication interface 540, and bus 550. Wherein processor 510, memory 520, input/output interface 530, and communication interface 540 enable a communication connection within the device between each other via bus 550.

The processor 510 may be implemented by a general-purpose CPU (Central Processing Unit ), a microprocessor, an application-specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc. for executing relevant programs to implement the technical solutions provided in the embodiments of the present disclosure.

The Memory 520 may be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory ), static storage device, dynamic storage device, or the like. Memory 520 may store an operating system and other application programs, and when the embodiments of the present disclosure are implemented in software or firmware, the associated program code is stored in memory 520 and executed by processor 510.

The input/output interface 530 is used for connecting with an input/output module to realize information input and output. The input/output module may be configured as a component in a device (not shown) or may be external to the device to provide corresponding functionality. Wherein the input devices may include a keyboard, mouse, touch screen, microphone, various types of sensors, etc., and the output devices may include a display, speaker, vibrator, indicator lights, etc.

The communication interface 540 is used to connect with a communication module (not shown in the figure) to enable communication interaction between the present device and other devices. The communication module may implement communication through a wired manner (such as USB, network cable, etc.), or may implement communication through a wireless manner (such as mobile network, WIFI, bluetooth, etc.).

Bus 550 includes a path to transfer information between elements of the device (e.g., processor 510, memory 520, input/output interface 530, and communication interface 540).

It should be noted that although the above device only shows the processor 510, the memory 520, the input/output interface 530, the communication interface 540, and the bus 550, in the implementation, the device may further include other components necessary for achieving normal operation. Furthermore, it will be understood by those skilled in the art that the above-described apparatus may include only the components necessary to implement the embodiments of the present description, and not all the components shown in the drawings.

Embodiments of the present invention also provide a non-transitory readable storage medium storing instructions for causing a computing device to perform a method according to embodiments of the present invention. The readable media of the present embodiments, including both permanent and non-permanent, removable and non-removable media, may be any method or technology for information storage. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of readable 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 technology, compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape disk storage, and the like.

In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the invention. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It should be appreciated that the teachings of the present invention as described herein may be implemented in a variety of programming languages and that the foregoing descriptions of specific languages are provided for disclosure of preferred embodiments of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the intention that: i.e., the claimed invention requires more features than are expressly recited in each claim. Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in the examples. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component, and furthermore they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination may be employed to combine all features disclosed in this specification (including the accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, unless at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments. Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element.

As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.

While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter.

Claims

1. An application access control method for controlling access of a subject application to a guest resource, comprising:

responding to an access request of a subject application to a guest resource, reading a strategy file which is set in advance, wherein the strategy file comprises a blacklist mode basic strategy module, the blacklist mode basic strategy module defines a blacklist of the subject application and the guest resource, and endows the subject application outside the blacklist with authority for accessing the guest resource outside the blacklist;

Judging whether the subject application and the object resource are in a blacklist or not according to the strategy file;

and if the subject application and the object resource are not in the blacklist, allowing the subject application to access the object resource according to the authority given by the blacklist mode basic strategy module.

2. The application access control method of claim 1, further comprising:

if any one or both of the subject application and the object resource are in the blacklist, inquiring the security policies of the subject application and the object resource in the policy file;

allowing the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define access rights of the subject application to the guest resource;

and if the security policies of the host application and the guest resource do not define the access authority of the host application to the guest resource, the host application is refused to access the guest resource.

3. The application access control method of claim 2, the security policy of the guest resource comprising one of: allowing any other application to access the guest resource; allowing the subject application to access the guest resource;

the security policy applied by the principal comprises one of: allowing the subject application to access any other applications; the subject application is allowed to access the guest resource.

4. The application access control method of any one of claim 1-3, wherein said blacklist mode base policy module is written based on a system-existing SELinux whitelist mechanism,

in the blacklist mode base policy module: defining a blacklist of subject application and object resources through attribute policy statements; defining subject application and object resources included in the blacklist through a type attribute strategy statement; by allowing policy statements, subject applications outside of the blacklist are given access to guest resources outside of the blacklist.

5. The application access control method of claim 4, further comprising:

in response to user input, the blacklist mode base policy module is offloaded to switch back to the SELinux whitelist mechanism of the kernel system.

6. An application access control apparatus for controlling access of a subject application to a guest resource, comprising:

the system comprises a reading module, a storage module and a storage module, wherein the reading module is used for responding to an access request of a subject application to a guest resource and reading a strategy file which is set in advance, the strategy file comprises a blacklist mode basic strategy module, the blacklist mode basic strategy module defines blacklists of the subject application and the guest resource, and the authority of the subject application outside the blacklist for accessing the guest resource outside the blacklist is given;

The judging module is used for judging whether the subject application and the object resource are in a blacklist or not according to the strategy file;

and the release module is used for allowing the subject application to access the object resource according to the authority given by the blacklist mode basic strategy module if the subject application and the object resource are not in the blacklist.

7. The application access control device of claim 6, further comprising:

the query module is used for querying the security policies of the subject application and the object resource in the policy file if any one or both of the subject application and the object resource are in the blacklist;

an access permission module, configured to permit the subject application to access the guest resource if one or both of the respective security policies of the subject application and the guest resource define an access right of the subject application to the guest resource;

and the rejecting module is used for rejecting the host application to access the object resource if the security policies of the host application and the object resource do not define the access authority of the host application to the object resource.

8. The application access control device of claim 6, the security policy of the guest resource comprising one of: allowing any other application to access the guest resource; allowing the subject application to access the guest resource;

9. A computing device, comprising:

at least one processor and a memory storing program instructions;

the program instructions, when read and executed by the processor, cause the computing device to perform the application access control method of any of claims 1-5.

10. A readable storage medium storing program instructions which, when read and executed by a computing device, cause the computing device to perform the application access control method of any of claims 1-5.