Apparatus and method for securely patching application in real time

Abstract

The invention relates to the field of endpoint security and security policy enforcement. A device (100) is provided for securely patching (101) an application (102) installed on the device (100) in real time. The device (100) is configured to: obtain the real-time patch (101) from a server; determining an attempt to execute a file system operation (103) based on a rule (104) stored in a security policy (105) in the device (100), where the attempt to execute the file system operation (103) is caused by the device (100) when attempting to patch the application (102) with the real-time patch (101); and according to the rule (104), forbidding the file system operation (103) to stamp the real-time patch (101) on the application (102).

Description

Technical Field

[0001] The present invention relates to the field of IT security, and in particular to mobile device security and security policy enforcement. Therefore, the present invention provides a device for safely applying real-time patches to applications installed on a device. In addition, the present invention also provides a corresponding method and computer program. Background Art

[0002] Application live patching is a method that enables an application to update its code and content after it has been installed on a mobile device, without requiring the end user to explicitly install the update or patch. An application that performs live patching typically downloads new executable code and / or content at runtime and dynamically loads the downloaded code or content to replace a portion of its original code or content. The downloaded executable code can be in the form of an executable program, a dynamically loadable shared library, compiled bytecode, or source code.

[0003] This type of approach is common in many applications for consumer devices such as mobile devices or cell phones, where the application developer embeds a live patch framework or library into the application to be released. Once the application is distributed by the application distributor and installed on the device, the live patch framework or library can check from time to time whether there are any updates from the live patch server. When the application developer decides to release an update in the form of a live patch, the developer can upload the patch to the live patch server so that the installed application can download the patch through the live patch framework or library and load the patch at runtime. Figure 5 This scenario is schematically illustrated.

[0004] Compared to normal app patches or updates, using a live patching approach allows app developers to distribute new content and bug fixes faster by avoiding delays that app distributors may introduce, and achieve wider coverage by silently installing updates without user interaction.

[0005] However, the silent installation nature of application live patches also means that such live patches are installed without user consent and without any automatic or manual checks performed by the application distributor. This can be abused by malware developers and distributors to bypass malware detection and countermeasures that are usually performed by application distributors during the normal application distribution and update process.

[0006] When developers use a malicious live patching framework or a library that downloads malware code from a server not intended by the app developer, even benign apps can be tricked into loading malicious code. It is also possible that the live patching framework or library is poorly designed and vulnerable to attack, so it can load malicious code injected by an attacker.

[0007] Traditional approaches that attempt to address this problem use a detect and block strategy that first detects the malware code and then blocks the app from launching or uninstalling it. This strategy is unsatisfactory in many ways. Most importantly, these approaches do not attempt to prevent the live patching actions performed by the app, but only deal with the results.

[0008] Therefore, traditional solutions cannot safely apply real-time patches to applications. Summary of the invention

[0009] In view of the above problems, an object of an embodiment of the present invention is to provide a method for safely applying real-time patches to applications installed on a device.

[0010] This object and others are achieved by the embodiments of the invention described in the attached independent claims. Advantageous implementations of the embodiments of the invention are further defined in the dependent claims.

[0011] A first aspect of the present invention provides a device, wherein the device is used to securely apply a real-time patch to an application installed on the device, and the device is used to: obtain the real-time patch from a server; determine an attempt to perform a file system operation based on a rule in a security policy stored in the device, wherein the attempt to perform the file system operation is caused by the device attempting to apply the real-time patch to the application; and prohibit the file system operation from applying the real-time patch to the application according to the rule.

[0012] This ensures that the application real-time patch management policy rules can be enforced using the mechanisms available on the operating system and consumer devices. The enforcement can be generic enough to be easily adapted to many different operating systems and devices.

[0013] In an implementation of the first aspect, the device is further configured to employ an event system to determine the attempt to perform a file system operation.

[0014] This ensures that file system operations can be easily detected.

[0015] In another implementation of the first aspect, the event system is used to monitor and / or intercept file system access.

[0016] This ensures that the action can be performed before accessing the file system.

[0017] In another implementation of the first aspect, the device is further configured to: configure the event system based on the rule to determine the attempt to perform the file system operation.

[0018] This ensures that precise instructions can be given according to which the event can be configured.

[0019] Specifically, the event system can be configured to monitor which path (eg, directory or file). Specifically, the event system can be configured to monitor which file system operations on a given path.

[0020] In another implementation of the first aspect, the event system configuration includes at least one of the following: inotify configuration and fanotify configuration.

[0021] Therefore, a device can use various configuration methods.

[0022] In another implementation of the first aspect, the device is further configured to update the event system configuration after performing the file system operation.

[0023] Thus, advantageously, the event system can adapt to new file system states.

[0024] In another implementation of the first aspect, the device is further configured to update the event system configuration according to the rule and based on a decision of the device to allow the file system operation.

[0025] Thus, advantageously, the event system can adapt to the decisions of the device.

[0026] In another implementation of the first aspect, the file system operation for applying the real-time patch includes at least one of the following: creating a file, modifying a file, accessing a file, creating a directory, modifying a directory, and accessing a directory.

[0027] This ensures that the device can detect various file system operations.

[0028] In another implementation of the first aspect, the rule includes at least one of the following: a path, an action.

[0029] This ensures that the file system operations that should be prohibited can be precisely defined in the rules.

[0030] In particular, the rule may also or alternatively include a class.

[0031] In another implementation of the first aspect, the path specifies a directory or file to consider when determining the attempt to perform a file system operation.

[0032] This ensures that the file system operations that should be prohibited can be defined more precisely in the rules.

[0033] In another implementation of the first aspect, the action includes at least one of the following: preventing operations on the file system, restoring operations on the file system, recording operations on the file system, and other actions.

[0034] This ensures that actions can be precisely defined.

[0035] In another implementation of the first aspect, the prohibiting the file system operation from applying the real-time patch includes at least one of the following: setting a read attribute and / or a write attribute of a file or a directory; and removing a file or a directory.

[0036] This ensures that effective countermeasures can be taken against file system operations.

[0037] In another implementation of the first aspect, the device is further used to: obtain an initial security policy configuration and / or a security policy update, and update the security policy and corresponding rules based on the initial security policy configuration and / or the security policy update.

[0038] This provides various methods for updating security policies and corresponding rules in the device.

[0039] A second aspect of the present invention provides a method, wherein the method is used to securely apply a real-time patch to an application installed on a device, and the method comprises the following steps: the device obtains a real-time patch from a server; the device determines an attempt to perform a file system operation based on a rule in a security policy stored in the device, wherein the attempt to perform the file system operation is caused by the device attempting to apply the real-time patch to the application; and according to the rule, the device prohibits the file system operation from applying the real-time patch to the application.

[0040] In an implementation of the second aspect, the method further includes: the device using an event system to determine the attempt to perform a file system operation.

[0041] In another implementation of the second aspect, the event system monitors and / or intercepts file system access.

[0042] In another implementation of the second aspect, the method further includes: the device configuring the event system based on the rule to determine the attempt to perform the file system operation.

[0043] In another implementation of the second aspect, the event system configuration includes at least one of the following: inotify configuration and fanotify configuration.

[0044] In another implementation of the second aspect, the method further includes: the device updating the event system configuration after performing the file system operation.

[0045] In another implementation of the second aspect, the method further includes: the device updating the event system configuration according to the rule and based on the device's decision to allow the file system operation.

[0046] In another implementation of the second aspect, the file system operation for applying the real-time patch includes at least one of the following: creating a file, modifying a file, accessing a file, creating a directory, modifying a directory, and accessing a directory.

[0047] In another implementation manner of the second aspect, the rule includes at least one of the following: a path, an action.

[0048] In another implementation of the second aspect, the path specifies a directory or file to consider when determining the attempt to perform a file system operation.

[0049] In another implementation of the second aspect, the action includes at least one of the following: preventing operations on the file system, restoring operations on the file system, recording operations on the file system, and other actions.

[0050] In another implementation of the second aspect, the prohibiting the file system operation from applying the real-time patch includes at least one of the following: setting a read attribute and / or a write attribute of a file or a directory; and removing a file or a directory.

[0051] In another implementation of the second aspect, the method further includes: the device obtaining an initial security policy configuration and / or a security policy update, and updating the security policy and corresponding rules based on the initial security policy configuration and / or the security policy update.

[0052] The second aspect and its implementations include the same advantages as the first aspect and its corresponding implementations.

[0053] A third aspect of the present invention provides a computer program, the computer program comprising instructions, and when the program is executed by a computer, the instructions cause the computer to execute the method according to the second aspect or any implementation thereof.

[0054] The third aspect includes the same advantages as the first aspect and its corresponding implementations.

[0055] It should be noted that all devices, elements, units and devices described in this application can be implemented in software or hardware elements or any type of combination thereof. All steps performed by various entities described in this application and the functions to be performed by various entities described are intended to refer to the corresponding entities for performing the corresponding steps and functions. Although in the description of the following specific embodiments, the specific functions or steps to be performed by the external entity are not reflected in the description of the specific detailed elements of the entity performing the specific steps or functions, it should be clear to the technician that these methods and functions can be implemented by corresponding software or hardware elements or any combination thereof. BRIEF DESCRIPTION OF THE DRAWINGS

[0056] In conjunction with the accompanying drawings, the following description of specific embodiments illustrates various aspects and implementations of the present invention. In the drawings:

[0057] Figure 1 A schematic diagram of a device provided by an embodiment of the present invention is shown;

[0058] Figure 2 A schematic diagram of a device provided by an embodiment of the present invention is shown in more detail;

[0059] Figure 3 A schematic diagram showing an operation scenario provided by an embodiment of the present invention is shown;

[0060] Figure 4 A schematic diagram of a method provided by an embodiment of the present invention is shown;

[0061] Figure 5 A schematic diagram of conventional real-time updating is shown. DETAILED DESCRIPTION

[0062] Figure 1 A schematic diagram of a device 100 is shown. The device 100 is used to securely apply a real-time patch 101 to an application 102 installed on the device 100. The device 100 is used to obtain the real-time patch 101 from a server. The real-time patch 101 may include an executable program, a dynamically loadable shared library, a compiled bytecode or a source code. The server is located outside the device 100 and is not included in the device 100. The device 100 is also used to determine an attempt to perform a file system operation 103. For example, the file system operation 103 is performed on a storage medium included in the device 100. The determination is based on a rule 104 of a security policy 105 stored in the device 100. The attempt to perform the file system operation 103 is caused by the device 100 when attempting to apply the real-time patch 101 to the application 102. That is, installing the real-time patch 101 involves the file system operation 103. According to the rule 104, the device 100 prohibits the file system operation 103 from applying the real-time patch 101 to the application 102. That is, for example, the file system operation is blocked, interrupted or reversed.

[0063] Thus, the device 100 uses mechanisms available, for example, on operating systems and consumer devices to enforce application real-time patch management policy rules.The enforcement algorithm executed by the device 100 may be generic so as to be easily adaptable to many different operating systems and devices.

[0064] An example of policy rule 104 is as follows:

[0065] {

[0066] "path": " / data / app / 500 / plugin / libxyz.so",

[0067] "type": "file",

[0068] "Deny": "Create",

[0069] }

[0070] For example, the exemplary rule 104 may specify that no file should be created on the path " / data / app / 500 / plugin / libxyz.so", which in the given example is located in the sandbox of the application "500". This may prevent the application "500" from downloading a live patch containing the shared library libxyz.so and placing the live patch in the specified path. In addition to denying the creation of files, other rules may also define that if a file exists, the file should not be modified, or that the creation and modification of the file should be reported.

[0071] Combined with the following Figure 2 The apparatus 100 is described in more detail. Figure 2 The device 100 comprises Figure 1 All functions and features of the device 100.

[0072] The present invention is directed to executing security policy rules 104, wherein some optional aspects are as follows: A method for preventing the creation, modification or access of files on paths specified by security policy rules 104. This may include: computing the minimum set of abstract event system 201 configurations and abstract file system operations 103 required to execute a given policy rule 104, including an abstract model of the event system 201 and the file system. Optionally, the present invention includes computing the event system configuration 202 (see Figure 2), the updating and appending of the file system operations 103 of the event system configuration 202 is required to continue to execute a given policy rule 104 after the file system event 103 occurs to indicate changes to the file system. The updated abstract event system configuration 202 can be kept minimal. Optionally, the present invention can map the abstract event system configuration 202 and the file system operations 103 to inotify and fanotify configurations and file system operations, for example, provided by a Linux-based operating system. Optional variants include: inotify only; other operating systems, with or without kernel changes. The policy rule 104 can specify that files are not allowed to be created, modified, or accessed on a given path in the file system, and can include additional information, such as other actions to be taken when an application attempts to create, modify, or access such files.

[0073] The present invention is particularly applicable to scenarios where applications installed on consumer device 100 can perform live patches, wherein executable code or bytecode can be downloaded from a live patch server and later loaded to replace or modify a portion of the existing code that was originally installed, and such changes to the application are silent, i.e., the end user is unaware of such changes.

[0074] Device 100 may load application live patch control policy 105, which contains rules 104, which specify actions to be taken when files and directories under specific paths are created, modified or accessed (read). Policy rules 104 may be updated from time to time.

[0075] More specifically, according to the present invention, the following components may be considered (each of which is optional): a consumer device (i.e., device 100) in which many applications capable of real-time patching may be installed. There may be a physical component that allows end-user interaction, such as a touch screen. An operating system hosted on device 100 that provides one or more file systems to host applications and their files; an event system 201 (e.g., a file system that can report and / or intercept file access by applications); Figure 2As shown). A file system provided by the operating system, in which applications can create or read and write files and directories. For example, the file system can provide basic UNIX-like file permissions for access control. The event system 201 provided by the operating system can be used to generate notifications about file access events that occur in the file system. The event system 201 can also provide certain blocking notifications that enable system services to make permission decisions. The real-time patch manager is a system service hosted on the operating system and is responsible for specifying real-time patch security policy rules. The policy engine is another system service hosted on the operating system and is responsible for enforcing such real-time patch security policy rules 104. Applications can execute real-time patches by downloading new code and content and loading the updated code at runtime.

[0076] An abstract model of an operating system, file system, and event system 201 that may be used by device 100 will be described below.

[0077] In an operating system, a file system (FS) can be viewed as a tree, where each node consists of a name and a set of access control attributes. A node can be a directory or a file. A file node can only be a leaf node of the tree, while a directory node can be either a leaf node or an intermediate node. The name of a node is unique among all the child nodes of its parent node.

[0078] The list of names from the root to a specific node can be called the path of the node in the file system. Since the names of child nodes under the same parent node are unique, the path of a node in the file system is the unique identifier of the node in the file system.

[0079] The access control attributes of nodes in the file system include at least read attributes and write attributes. If a node has a read attribute, its content can be accessed by applications. If a node has a write attribute, its content can be modified by applications. For a directory node, its content can contain the name and a collection of attributes of its child nodes. For a file node, its content can contain arbitrary data. The content of a node can be empty. It should be noted that regardless of these attributes, the policy engine should have full access to all nodes in the file system.

[0080] More formally, a file system (hereinafter also referred to as "FS") can be a collection of nodes, where each node n can be written as a tuple in the FS

[0081] n=<parent node, name, path, type, attribute>

[0082] The parent node can be nil (for the root node) or another node in FS. The path of node n can be recursively derived from the name and path of the parent node. That is, n.path = (p.parent.path, n.name), where the brackets mean appending additional elements (n.name) to the existing list (p.parent.path). For convenience, the path of a nil node can be defined as an empty list. It can also be required that there is exactly one node in FS whose parent node is nil, and the paths of all nodes in FS are lists with finite elements. In other words, FS can be a tree.

[0083] The following node functions (which may be file system operations 103, for example) may be applied to a given node in the file system FS by both the application and the policy engine:

[0084] 1. Removal: A node can be a leaf node or an intermediate node representing a subtree and can be removed from the file system. The root node cannot be removed.

[0085] 2. Insert (child node): You can insert a new leaf node (child node) under an existing node (parent node) in the tree. The parent node must be a directory node.

[0086] 3. Move (parent, name): The subtree identified by node (i.e., the root of the subtree) can be detached from its current parent and reattached to a new parent in the tree with a new name. The new parent and new name can be the same as the old parent and old name. This can be viewed as a sequence of subtree deletions followed by one or more node insertions. The name and attributes of the descending node of the root of the moved subtree remain unchanged.

[0087] 4.ModifyAttributes(±attr): You can modify the access control attributes of a node by adding (+) or removing (–) the attribute attr in the node. For example, “–write” means removing the “write” attribute.

[0088] 5.ModifyContent(content): Modify a file node with new content. The new content can contain arbitrary data. For directory nodes, their content is only indirectly modified when a subtree is deleted, a node is inserted, a subtree is moved, or an attribute is modified.

[0089] 6. Access: Retrieve the contents of the node from the file system. This function does not change the file system like other functions.

[0090] The operation op can be represented by a tuple

[0091] op = <path, function>

[0092] Wherein, path may identify an existing node in the file system, and function may refer to one or more functions as defined above, including the required parameters. It may be assumed that operations (functions) that change the file system can only be performed sequentially.

[0093] The file system's event system 201 can be a source of a series of events that can be configured to generate events when the file system changes in a particular way. Each event e can be a tuple

[0094] e=<path, type, data>

[0095] The path of an event is the path of the node in the file system that is related to the event. Data is the auxiliary data associated with the event. The type of an event can be one of the following possible values:

[0096] 1. Insertion: This event can be generated after a node insertion or a subtree move. For a node insertion, the event path can be the path of the parent node of the new node. For a subtree move, the event path can be the path of the target parent node of the subtree after the move. In both cases, the event data contains the name of the new child node of the node identified by the path.

[0097] 2. Delete: This event can be generated after a subtree is deleted or a subtree is moved. The path of the event identifies the path of nodes in the subtree before the move or deletion.

[0098] 3.ModifyContent: This event can be generated after a file system operation causes the content of a file system node to change. For subtree deletion, the path refers to the parent node of the deleted subtree. For node insertion, the path refers to the parent node of the new node. For subtree movement, two ModifyContent events can be generated, where the path of one event identifies the parent node of the subtree before the move, and the path of the other event identifies the parent node of the subtree after the move. In all cases, the event data contains information indicating which of the above operations generated the event.

[0099] 4.ModifyAttribute: This event can be generated when the attribute of a node is modified.

[0100] 5. Pre-open: This event can be generated before the content access and content modification operations are performed on the file node in the file system. The path can identify the node being accessed or modified, and the event data indicates whether the operation is to access or modify the node content.

[0101] The event system 201 may also generate other types of events.

[0102] The event system 201 can be configured by the policy engine to generate a subset of all possible events that can be generated. An event configuration (C) is a collection of tuples of the form

[0103] c=<path, type>

[0104] Where type is the set of types listed above and path must be the path to an existing node in the file system at the time the configuration takes effect. A configuration c where the path does not identify any existing node in the file system is considered invalid.

[0105] When a pre-open event occurs, the expected file system node function is suspended until the policy engine sends a response to the event system 201. Depending on the response, the operation can be allowed or denied. The following functions can be defined, which can be applied by the policy engine as a response to a pre-open event.

[0106] 1. Allow(event): This tells the file system that the intended node function indicated by the event is allowed.

[0107] 2. Reject (event): This informs the file system that the intended node function indicated by the event is not allowed. Therefore, the node function will not be applied to the file system.

[0108] Optional aspects of the concept of security policy 105 are defined in more detail below.

[0109] A security policy P (e.g., security policy 105) can be viewed as a set of rules, where each rule r in P (e.g., rule 104) is a tuple

[0110] r = <path, class, action>

[0111] The rule path can refer to a node in the file system, which may or may not exist when the rule takes effect. The rule class can be one of the following:

[0112] 1. Create: This type of rule 104 may be executed when the node identified by the path appears in the file system but does not exist when the rule takes effect. This type of scenario may occur when the file system is changed by node insertion or subtree movement.

[0113] 2. Update: This class of rules 104 can be executed when the content of an existing node in the file system identified by the path is modified. For a file node, this refers to a change in the file content. For a directory node, this refers to a change in the list of files and directories under the node. In other words, inserting a new node or removing an existing node under a directory node matches this class.

[0114] 3. Open: This type of rule 104 may be executed when a node in the file system identified by a path is to be accessed (read) or modified (written).

[0115] The regular actions can be a set of actions that should be taken when executing Rule 104 according to the path and class, and can be one of the following:

[0116] 1. Restore: Changes to the file system can be restored.

[0117] 2. Intercept: Operations on the file system can be blocked before they are performed.

[0118] 3. Others: Other actions that may be required. For example, file system operations that trigger Rule 104 can be logged and reported for further analysis.

[0119] Optional aspects of the rule base will be described in more detail below. To allow the execution of Policy Rule 104, the policy engine can configure the event system 201 to receive relevant events. A specific policy rule 104 and the rule base of the file system FS can be defined as an event configuration 202 and a file system operation, and the file system operation allows the rule to be executed when given the current state of a given file system. More formally, the rule base b can be represented by a tuple

[0120] b = <r, path, type, function>

[0121] where r is a reference to Rule 104 on which the computational basis depends, type is the type of event that should be received on the path (i.e., <path, type> is a valid event configuration as defined above), and function is a set of file system functions to be applied to the file system on the path (i.e., <path, function> is a file system operation).

[0122] If, for any other rule base b' for the same rule r, the cardinality of b.functions is not greater than that of b'.functions (i.e., |b.functions| ≤ |b'.functions|), and for b' where |b.functions| = |b'.functions|, the cardinality of b.types is not greater than that of b'.types (i.e., |b.types| ≤ |b'.types|), then the rule base b is minimal. In other words, if the rule base b first minimizes the number of file system functions required and then minimizes the number of events, then the rule base b is minimal.

[0123] Given a rule base b and an event configuration c, c can cover b (equivalently, b is covered by c) if and only if b.path is the same as c.path and b.types is a subset of c.types. Similarly, given a rule base b and a file system operation op, op can cover b (or equivalently, b is covered by op) if and only if b.path is the same as op.path and b.functions is a subset of op.functions.

[0124] A policy configuration can be defined as a tuple<B,C,O> , where B may be the set of rule bases for all rules 104 in policy 105, C may be the set of valid event configurations, and O may be the set of file system operations. If for each rule base b in B, there exists an event configuration c in C and a file operation op in O such that b is covered by c and op, then the policy<B,C,O> is reasonable. If every rule basis b in B is minimal, then a reasonable strategy<B,C,O> is minimal, and for any other reasonable strategy<B',C',O'> , |C|≤|C'| and |O|≤|O'|.

[0125] In the present invention, three algorithms are designed as described below. The first algorithm RuleBasis can calculate the basis of the rules 104 in a given policy 105 and file system. The second algorithm PolicyConfig can calculate the event configuration C and the set of operations based on the policy P and the file system FS, and the third algorithm ConfigUpdate can calculate the new configuration C' and operation O' when the policy or file system has changed.

[0126] The algorithm should satisfy the following properties:

[0127] Property 1 (reasonableness): At any time, for the current policy P and file system FS, the policy configuration calculated by PolicyConfig and ConfigUpdate<B,C,O> Should always be reasonable.

[0128] The algorithm should also satisfy the second property:

[0129] Property 2 (efficiency): At any time, for the current policy P and file system FS, the policy configuration calculated by PolicyConfig and ConfigUpdate<B,C,O> Should always be minimal.

[0130] In order to calculate the rule basis for rule r (i.e., rule 104) in a given policy P (i.e., security policy 105) and a file system FS, first, the path cursor of each rule r can be calculated as follows: Each cursor = <index, path> can contain an index and the longest matching path identifying an existing node in the file system, and the index indicates the number of path names in rule 104 that do not match existing nodes in the file system.

[0131] RuleCursor(r,FS):

[0132]

[0133] The notation list [0,i] denotes a slice of a list containing the first i+1 elements. A path can be a list of names. Thus, a slice of the path to a node can identify the intermediate nodes from the root to that node. The purpose of a RuleCursor is to know the longest prefix of a rule path that has a corresponding node in the file system. A cursor with index 0 indicates that the entire rule path matches an existing node in the file system. This information can be used to compute the configuration required to execute the rule.

[0134] With the above algorithm as building blocks, the configuration and file system changes required for a rule r can be computed as follows. Each rule base is a tuple containing a reference to the rule from which the rule base was generated, a path identifying an existing node in the file system, a collection of event types, and a collection of functions to be performed on the file system at the path.

[0135] RuleBasis(r,FS):

[0136]

[0137] The ModifyAttributes function is an operation that changes the attributes of nodes on a given path. It should be noted that for the rule base b, the tuple<b.path,b.types> Form a valid event configuration, tuple<b.path,b.functions> Form a file system operation.

[0138] In the rule base set of the rules 104 in the policy 105, the minimum event configuration set required can be determined first. This can be achieved by the following algorithm.

[0139] EventConf(basis):

[0140]

[0141]

[0142] Similarly, the set of file system operations required for a given basis can be computed:

[0143] FSOperations(basis):

[0144]

[0145] Now, the required policy configuration for a given file system FS and policy P is calculated as follows. Each policy configuration can be a tuple containing the rule base for all rules, the collection of event configurations required to configure the event system, and the collection of file system operations to be applied to the file system.

[0146] PolicyConfig(P,FS):

[0147]

[0148] After generating the policy configuration, the policy engine can perform these file system operations and use the event configuration to configure the event system.

[0149] If the update of the policy configuration is caused by a change in policy 105, the new configuration can be obtained by the above-mentioned PolicyConfig algorithm. If most rules remain unchanged and only a small number of rules 104 change, it is possible to achieve optimization. For example, the differences of the policy rules can be calculated first, and then only the differences can be processed.

[0150] On the other hand, if an event e=<path, type, data> is received from the event system as a result of the current event configuration, then the event system may need to be reconfigured and necessary operations performed on the file system in order to enforce the policy. The new configuration is obtained by the following algorithm, where e is the received event, C is the current policy configuration, P is the policy, and FS is the current file system after the event.

[0151] UpdateConfig(e,C,P,FS):

[0152]

[0153]

[0154] If the underlying file system does not support pre-open events, a variation of the RuleBasis algorithm discussed earlier can be used to check if the event refers to a change in a node attribute. If the attribute is changed and the rule class is open, then a file operation needs to be added to remove both the read and write attributes.

[0155] Combine the following Figure 3 Describe the operating scenario of the device 100. Assume that there is a system service "Real-time Patch Manager" hosted on the target operating system, which can be responsible for providing initial security policy rules 104 and subsequent updates. Further assume that there is a second system service "Policy Engine" hosted on the same operating system, which is responsible for enforcing such security rules. Figure 3 The overall system implementation is shown.

[0156] As shown, after initially configuring a security policy or subsequently updating a security policy, the policy engine may first calculate (or recalculate) a rule base from which a policy configuration is generated, perform file system operations, and configure or reconfigure the event system based on the policy configuration.

[0157] When Application 102 (while attempting to apply the live patch 101 to Application 102) attempts to create, modify, or access a file or directory, if an event is configured for the target path, such an event will be triggered by the file system and the event system. After receiving the event, the policy engine will update its current policy configuration and reconfigure the file system and the event system if necessary.

[0158] The UpdateEventSystem algorithm can be implementation-specific, as further described below.

[0159] As described above, it can be proven that the algorithm for calculating the rule basis for a given policy rule and the current file system is correct. In other words, for a rule basis b = <r, path, type, function>, the event configuration <b.path, b.types> and the file system operations <b.path, b.functions> are sufficient to support the execution of rule r.

[0160] Lemma 1 (RuleBasis): The rule basis <r, path, type, function> calculated by the algorithm RuleBasis for rule r and file system FS is always sufficient and minimal.

[0161] Next, for each policy configuration <B, C, O> calculated by the PolicyConfig algorithm for a given policy and the current state of the file system, it can be proven according to the definitions given above that the policy configuration <B, C, O> is always sound and minimal. This means that given the current state of the file system, the event configuration and the file system operations are sufficient to execute all policy rules, and the file operations and events are minimized.

[0162] Lemma 2 (PolicyConfig): The configuration calculated by PolicyConfig is always sound and minimal.

[0163] Finally, the soundness requirement of the configuration update algorithm (ConfigUpdate) is that the modified policy configuration is sound and minimal.

[0164] Lemma 3 (ConfigUpdate): After an event occurs, the new policy configuration <B, C, O> calculated by ConfigUpdate is always sound and minimal for the file system.

[0165] This section describes the method of implementing the abstract algorithms using the inotify and fanotify APIs in a Linux-based system.

[0166] Since the abstract file system may follow the real Linux file system, file system operations (e.g., changing file attributes) can be directly mapped to the corresponding chmod function, while removing files and directories can be mapped to calls to nftw and remove functions, but the premise is that it is implemented in C language with a standard library.

[0167] When both inotify and fanotify are available on the target operating system, the event configuration can be mapped to the actual API call as follows:

[0168] First, the only fanotify configuration required is the pre-open event, where a marker of type FAN_OPEN_PERM is added to the corresponding path. The remaining events are implemented as inotify watchpoints with appropriate masks, where insert maps to (IN_CREATE|IN_MOVED_TO), delete maps to IN_DELETE_SELF, and ModifyAttribute maps to IN_ATTRIB.

[0169] Additionally, the following steps are followed during the policy update process to convert the event configuration changes from EC to EC' into corresponding inotify and fanotify API calls.

[0170] UpdateEventSystem(EC,EC'):

[0171]

[0172] Another important consideration in actually implementing the abstract algorithm is handling concurrent changes to the file system. Since our algorithm assumes that changes and events in the file system and event system are always sequential, there are scenarios where the algorithm may fail due to concurrent changes. For example, when the application creates a new directory that matches a partial path of rule 104, the algorithm should add a new inotify watchpoint for that directory. However, if a further directory is created under that new directory before the watchpoint can be added, the directory creation event will be missed, resulting in inaccurate execution. One way to handle such scenarios is to rerun the RuleBasis algorithm periodically to check if there are any inconsistencies between the actual file system and the rule basis that has been calculated. Another option is to arrange for a delayed basis calculation to be performed whenever a new directory matching the rule path is created.

[0173] Make abstract model and algorithm useful under normal circumstances, need to consider the scene that file system or event system are different from previous embodiment.For example, in some systems based on Linux, fanotify API may be unavailable.In this case, pre-opening event is unavailable in event system.In this case, pre-opening event configuration can be mapped to all access flags of removing file and set inotify observation point to monitor the file system operation of attribute change.In this way, target file just can't be opened by application in fact.

[0174] In another example, if these algorithms are to be implemented in a completely different operating system (e.g., Microsoft Windows), an event system must first be developed using a Windows file system filter driver that mimics the behavior of inotify and fanotify before the first embodiment can be applied. Other more efficient APIs may also be developed that are easier to map and process.

[0175] In another example, the fanotify implementation can be modified so that the file open flag is passed to the policy engine so that the policy engine knows how the file is opened. In this case, the pre-open can do event monitoring and deny access when the writable flag is present, rather than removing the writable flag on the file and monitoring attribute changes.

[0176] Figure 4 A schematic diagram of a method 400 is shown. The method 400 is used to securely apply a real-time patch 101 to an application 102 installed on a device 100. The method 400 comprises a first step, namely the device 100 obtains 401 the real-time patch 101 from a server. The method comprises a second step, namely the device 100 determines 402 an attempt to perform a file system operation 103 based on a rule 104 in a security policy 105 stored in the device 100, wherein the attempt to perform the file system operation 103 is caused by the device 100 attempting to apply the real-time patch 101 to the application 102. The method comprises a third step, namely the device 100 prohibits 403 the file system operation 103 from applying the real-time patch 101 to the application 102 according to the rule.

[0177] The invention has been described in conjunction with various embodiments as examples and in conjunction with implementations. However, other variations will be understood and implemented by a person skilled in the art in practicing the claimed invention, based on a study of the drawings, the invention and the independent claims. In the claims as well as in the specification, the word "comprising" does not exclude other elements or steps, and the indefinite article "a" or "an" does not exclude a plurality. A single element or other unit may fulfil the functions of several entities or items described in the claims. The fact that certain measures are recited in mutually different dependent claims does not in itself mean that a combination of these measures cannot be used in an advantageous implementation.

Claims

1. A device (100), characterized in that: The device (100) is used to securely apply a real-time patch (101) to an application (102) installed on the device (100), and the device (100) is used to: Obtain the real-time patch from the server (101); Determining an attempt to perform a file system operation (103) based on a rule (104) in a security policy (105) stored in the device (100), wherein the attempt to perform the file system operation (103) is caused by the device (100) attempting to apply the real-time patch (101) to the application (102); According to the rule (104), the file system operation (103) is prohibited from applying the real-time patch (101) to the application (102).

2. The device (100) according to claim 1, characterized in that The device (100) is further configured to employ an event system (201) to determine the attempt to perform a file system operation (103).

3. The device (100) according to claim 2, characterized in that The event system (201) is used to monitor and / or intercept file system access.

4. The device (100) according to claim 2 or 3, characterized in that The device (100) is further configured to configure (202) the event system (201) based on the rule (104) to determine the attempt to perform the file system operation (103).

5. The device (100) according to claim 4, characterized in that The event system configuration (202) includes at least one of the following: inotify configuration, fanotify configuration.

6. The device (100) according to claim 4 or 5, characterized in that The device (100) is also used to update the event system configuration (202) after performing the file system operation (103).

7. The device (100) according to any one of the preceding claims, characterized in that The device (100) is further configured to update the event system configuration (202) according to the rule (104) and based on the decision of the device (100) to allow the file system operation (103).

8. The device (100) according to any one of the preceding claims, characterized in that The file system operation (103) for applying the real-time patch (101) includes at least one of the following: creating a file, modifying a file, accessing a file, creating a directory, modifying a directory, and accessing a directory.

9. The device (100) according to any one of the preceding claims, characterized in that The rule (104) includes at least one of the following: a path, an action.

10. The device (100) according to claim 9, characterized in that The path specifies a directory or file to be considered when determining the attempt to perform a file system operation (103).

11. The device (100) according to claim 9 or 10, characterized in that The action includes at least one of the following: preventing operations on the file system, restoring operations on the file system, recording operations on the file system, and other actions.

12. The device (100) according to any one of the preceding claims, characterized in that The prohibiting the file system operation (103) from applying the real-time patch (101) comprises at least one of the following: setting a read attribute and / or a write attribute of a file or a directory; and removing a file or a directory.

13. The device (100) according to any one of the preceding claims, characterized in that The device (100) is also used to obtain an initial security policy configuration and / or a security policy update, and update the security policy (105) and corresponding rules (104) based on the initial security policy configuration and / or the security policy update.

14. A method (400), characterized in that The method (400) is used to safely apply a real-time patch (101) to an application (102) installed on a device (100), and the method (400) comprises the following steps: The device (100) obtains (401) a real-time patch (101) from a server; The device (100) determines (402) based on a rule (104) in a security policy (105) stored in the device (100) to attempt to perform a file system operation (103), wherein the attempt to perform the file system operation (103) is caused by the device (100) attempting to apply the real-time patch (101) to the application (102); According to the rule (403), the device (100) prohibits the file system operation (103) from applying the real-time patch (101) to the application (102).

15. A computer program, characterized in that The computer program comprises instructions which, when executed by a computer, cause the computer to perform the method according to claim 14 .

Images