TECHNICAL FIELD

The present disclosure relates to the field of IT security, in particular mobile device security and security policy enforcement. The present disclosure therefore provides a device for securely applying a live patch to an application installed on the device. Moreover, the present disclosure provides a corresponding method and computer program.

BACKGROUND

Application live-patch refers to a method that allows an application to update its code and content after it is installed on a mobile device, without an end-user explicitly installing an update or a patch. Typically, an application performing live-patch would download new executable code and/or content during runtime and dynamically load downloaded code or content so that part of its original code or content is replaced. The downloaded executable code may be in the form of an executable program or in the form of dynamically loadable shared libraries, compiled bytecode, or source code.

Such methods are commonly observed in many applications for consumer devices such as mobile devices or mobile phones, where an application developer embeds a live-patch framework or library into the application to be published. Once the application is distributed by an application distributor and installed on a device, the live-patch framework or library can check from a live-patch server from time to time to see if there is any update. When the application developer decides to publish an update in the form of a live-patch, the developer can upload the patch to the live-patch server, so that the installed applications can download the patches via the live-patch framework or library and load them during runtime. Such a scenario is schematically illustrated in FIG. 5.

Compared with normal application patches or updates, using live-patch methods allows application developers to distribute new content and bug fixes much faster by avoiding the delay that may be introduced by the application distributor, and to achieve much wider coverage by silently installing the updates without user interaction. However, the silent installation nature of application live-patch also means that such live-patch is installed without user consent, and without any automated or manual checks done by the application distributor. This may be abused by malware developers and distributors to by-pass malware detections and counter measures that are typically performed by the application distributor during normal application distribution and update processes.

Even benign applications can be tricked into loading malicious code when the developers used a malicious live-patch framework or a library that would download malware code from a server that is unintended by the application developers. It is also possible that the live-patch framework or library is not well-designed and easily attacked, so that it may load malicious code injected by an attacker.

Conventional solutions which try to address this problem employ a detect-and-block strategy, where malware code is first detected, and after that an application is prevented from launching or is uninstalled. Such a strategy is unsatisfactory in a number of ways. Most importantly, these methods do not attempt to prevent the live patch operations done by the applications and only handles the result.

As a result, conventional solutions cannot securely apply a live patch to an application.

SUMMARY

In view of the above-mentioned problem, an objective of embodiments of the present disclosure is to provide a way for securely applying a live patch to an application installed on a device

This or other objectives may be achieved by embodiments of the present disclosure as described in the enclosed independent claims. Advantageous implementations of embodiments of the present disclosure are further defined in the dependent claims.

A first aspect of the present disclosure provides a device for securely applying a live patch to an application installed on the device, wherein the device is configured to obtain the live 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 in attempting to apply the live patch to the application; depending on the rule, prohibit the file system operation from applying the live patch to the application. This ensures that application live-patch management policy rules can be enforced using mechanisms available on operating systems and consumer devices. The enforcement can be generic enough so that it can be easily adapted to many different operating systems and devices.

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

This ensures that file system operations can be easily detected.

In a further implementation form of the first aspect, the even system is configured to monitor and/or intercept a file system access.

This ensures that actions can be performed, before the file system is accessed.

In a further implementation form of the first aspect, the device is further configured to configure the event system for determining the attempt to perform the file system operation, based on the rule.

This ensures that precise instructions can be given based on which the event can be configured.

In particular, it can be configured which path (e.g., directory or file) is monitored by the event system. In particular, it can be configured which file system operations are monitored by the event system at the given path.

In a further implementation form of the first aspect, the event system configuration comprises at least one of: inotify configuration, fanotify configuration

Thereby, various configuration means can be used by the device.

In a further implementation form of the first aspect, the device is further configured to update the event system configuration after performing the file system operation.

Thereby, the event system can advantageously be adapted to the new file system state. In a further implementation form of the first aspect, the device is further configured to update the event system configuration depending on the rule and based on a decision of the device to allow the file system operation.

Thereby, the event system can advantageously be adapted to a decision of the device.

In a further implementation form of the first aspect, the file system operation to apply the live patch comprises at least one of creating a file, modifying a file, accessing a file, creating a directory, modifying a directory, accessing a directory.

This ensures that various file system operations can be detected by the device.

In a further implementation form of the first aspect, the rule comprises at least one of a path, an action.

This ensures that it can be precisely defined in the rule, which file system operation should be prohibited.

In particular, the rule may also or alternatively comprise a class.

In a further implementation form of the first aspect, the path specifies a directory or file to consider when determining the attempt to perform the file system operation.

This ensures that it can be even more precisely defined in the rule, which file system operation should be prohibited.

In a further implementation form of the first aspect, the action comprises at least one of preventing an operation on a file system, reverting an operation on a file system, logging an operation on a file system, other action.

This ensures that actions can be precisely defined. In a further implementation form of the first aspect, prohibiting the file system operation from applying the live patch includes at least one of setting a read attribute and/or a write attribute of a file or a directory; removing a file or a directory.

This ensures that effective countermeasures against a file system operation can be applied.

In a further implementation form of the first aspect, the device is further configured 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.

This provides various means for updating the security policy and corresponding rules in the device.

A second aspect of the present disclosure provides a method for securely applying a live patch to an application installed on a device, wherein the method comprises the steps of obtaining, by the device, a live patch from a server; determining, by the device, 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 in attempting to apply the live patch to the application; depending on the rule, prohibiting, by the device, the file system operation from applying the live patch to the application.

In an implementation form of the second aspect, the method further comprises employing, by the device, an event system to determine the attempt to perform the file system operation.

In a further implementation form of the second aspect, the even system monitors and/or intercepts a file system access.

In a further implementation form of the second aspect, the method further comprises configuring, by the device, the event system for determining the attempt to perform the file system operation, based on the rule.

In a further implementation form of the second aspect, the event system configuration comprises at least one of inotify configuration, fanotify configuration In a further implementation form of the second aspect, the method further comprises updating, by the device, the event system configuration after performing the file system operation.

In a further implementation form of the second aspect, the method further comprises updating, by the device, the event system configuration depending on the rule and based on a decision of the device to allow the file system operation.

In a further implementation form of the second aspect, the file system operation to apply the live patch comprises at least one of: creating a file, modifying a file, accessing a file, creating a directory, modifying a directory, accessing a directory.

In a further implementation form of the second aspect, the rule comprises at least one of: a path, an action.

In a further implementation form of the second aspect, the path specifies a directory or file to consider when determining the attempt to perform the file system operation.

In a further implementation form of the second aspect, the action comprises at least one of: preventing an operation on a file system, reverting an operation on a file system, logging an operation on a file system, other action.

In a further implementation form of the second aspect, prohibiting the file system operation from applying the live patch includes at least one of: setting a read attribute and/or a write attribute of a file or a directory; removing a file or a directory.

In a further implementation form of the second aspect, the method further comprises obtaining, by the device, 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.

The second aspect and its implementation forms include the same advantages as the first aspect and its respective implementation forms. A third aspect of the present disclosure provides a computer program comprising instructions which, when the program is executed by a computer, cause the computer to perform the method according to the second aspects or any of its implementation forms.

The third aspect includes the same advantages as the first aspect and its respective implementation forms.

It has to be noted that all devices, elements, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof.

BRIEF DESCRIPTION OF DRAWINGS

The above-described aspects and implementation forms of the present disclosure will be explained in the following description of specific embodiments in relation to the enclosed drawings, in which

FIG. 1 shows a schematic view of a device according to an embodiment of the present disclosure;

FIG. 2 shows a schematic view of a device according to an embodiment of the present disclosure in more detail;

FIG. 3 shows a schematic view of an operating scenario according to an embodiment of the present disclosure;

FIG. 4 shows a schematic view of a method according to an embodiment of the present disclosure; and

FIG. 5 shows a schematic view of conventional live update. DETAILED DESCRIPTION OF EMBODIMENTS

FIG. 1 shows a schematic view of a device 100. The device 100 is for securely applying a live patch 101 to an application 102 installed on the device 100. The device 100 is configured to obtain the live patch 101 from a server. The live patch 101 may comprise an executable program, a dynamically loadable shared library, compiled bytecode, or source code. The server is external to the device 100 and not comprised by the device 100. The device 100 is further configured to determine an attempt to perform a file system operation 103. The file system operation 103 happen e.g. on a storage medium comprised by the device 100. The determination is based on a rule 104 of a security policy 105 that is stored in the device 100. The attempt to perform the file system operation 103 is caused by the device 100 in attempting to apply the live patch 101 to the application 102. That is, installing the live patch 101 involves the file system operation 103. Depending on the rule 104 the device 100 prohibits the file system operation 103 from applying the live patch 101 to the application 102. That is, the file system operation is e.g., prevented, interrupted, or reversed.

The device 100 thus enforces application live-patch management policy rules using e.g. mechanisms available on operating systems and consumer devices. The enforcement algorithm performed by the device 100 can be generic, so that it can be easily adapted to many different operating systems and devices.

An example of a policy rule 104 is shown below:

{

“path” : “/data/app/500/plugin/libxyz.so”,

“type” : “file”,

“deny” : “create”,

}

This exemplary rule 104 e.g., may specify that no file should be created at path “/data/app/500/plugin/libxyz.so”, which, in the given example, is within a sandbox of application “500”. This may prevent the application “500” from downloading a live-patch that contains a shared library libxyz.so and put it into the specified path. Instead of denying the creation of the file, it may also be defined in other rules, that if the file exists then it should not be modified, or that creation and modification of the file should be reported. The device 100 is now going to be described in more detail in view of FIG. 2. The device 100 of FIG. 2 includes all functions and features of the device 100 as described in view of FIG. 1.

The present disclosure aims at enforcing security policy rules 104, wherein some optional aspects are as follows: A way to prevent file creation, modification or access at paths specified by a security policy rule 104. This may include computing a minimum set of abstract event system 201 configurations and abstract file system operations 103 that are required to enforce given policy rules 104, including an abstract model of the event system 201 and file system. The present disclosure optionally comprises a way of computing an update of the event system configuration 202 (cf. FIG. 2) and additional file system operations 103 that are required to continue enforcing given policy rules 104 after a file system event 103 has occurred to signal a change to the file system. The updated abstract event system configuration 202 may remain minimal. Optionally, the present disclosure may map abstract event system configurations 202 and file system operations 103 to inotify and fanotify configurations and file system operations e.g., provided by a Linux-based operating system. Optional variations are possible: inotify only; with or without kernel changes, other operating systems. A policy rule 104 may specify that file creation, modification or access are not permitted at a given path in the file system, and may contain additional information such other actions to be taken when applications attempts to create, modify or access such files.

The present disclosure in particular can be applied to a scenario where applications installed on a consumer device 100 may perform live-patch, where executable code or bytecode can be downloaded from a live-patch server and later loaded to replace or modify a part of existing code that was originally installed, and such changes of applications are silent in the sense that end users are not aware of them.

The device 100 may be loaded with an application live-patch control policy 105 that contains rules 104 that specify actions to be taken when files and directories under specific paths are created, modified or accessed (read). The policy rules 104 may be updated from time to time.

More specifically, the following components can be considered (each of which is optional) according to the present disclosure: A consumer device (i.e., the device 100), where a number of applications capable of live-patching can be installed. There may be physical components to allow end user interaction, such as a touch screen. An operating system, hosted on the device 100, providing one or more file systems to host the applications and their files, and an event system 201 (as illustrated in FIG. 2) that is capable of reporting and/or intercepting file accesses made by the applications. A file system, provided by the operating system, where applications may create, read or write files and directories. E.g., basic UNIX-like file permissions can be provided by the file system for access control. An event system 201, provided by the operating system, can be configured to generate notifications about file access events occurred in the file system. The event system 201 may further provide certain blocking notifications that allow permission decisions to be made by a system service. A Live Patch Manager, which is a system service hosted on the operating system, responsible for specifying live-patch security policy rules. A policy engine, which is another system service hosted on the operating system, responsible for enforcing such live-patch security policy rules 104. An application, which may perform live-patch by downloading new code and content and loading the updated code during run-time.

In the following, an abstract model of an operating system, file system and event system 201 which can be used by the device 100 is going to be described.

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

The list of names from the root to a particular node can be called the path of the node in the file system. Since the names of child nodes are unique under the same parent node, the path of a node in a file system serves as a unique identifier of the node in the file system.

The access control attributes of a node in a file system comprise at least a read attribute and a write attribute. 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 may contain the set of names and attributes of its child nodes. For a file node, its content may contain arbitrary data. The content of a node may be empty. It is to be noted that a policy engine should have full access to all the nodes in the file system regardless of these attributes. More formally, a file system (which is also referred to as “FS” in the following) can be a set of nodes, and where each node n can be written in FS as a tuple n = <parent, name, path, type, attributes^ where parent can be either nil (for the root node), or another node in the FS. The path for node n can be derived from the name and path of the parent node recursively. That is, n.path = (p.parent.path, n.name), where the parenthesis refers to appending an additional element n.name) to an existing list (p.parent.path). For convenience, it can be defined that the path of the nil node is an empty list. It may further be required that there is exactly one node in the FS whose parent is nil, and that the paths of all nodes in the FS are lists with finite elements. In other words, the FS can be a tree.

The following node functions (which e.g., can be the file system operations 103) can be applied on a given node in a file system FS by both applications and the policy engine:

1. Remove: The node, which is either leaf node or an intermediate node representing a subtree, can be removed from the file system. The root node cannot be removed.

2. Insert(child): A new leaf node (child) can be inserted under the existing node (parent) in the tree. The parent node must be a directory node.

3. Move(parent, name): The subtree identified by the node (i.e., root of the subtree) can be detached from its current parent node and attached again to a new parent node in the tree with a new name. The new parent node and the new name may be the same as the old parent and old name. This may be considered as a sequence of a subtree deletion followed by one or more node insertions. The names and the attributes of the descending nodes of the root of the subtree being moved remain the same.

4. Modify Attributes(±attr): The access control attributes of the node can be modified by adding (+) or removing (-) an attribute attr to or from the node. For example “-write” refers to removing the “write” attribute.

5. ModifyContent(content): Modify the file node with new content. The new content may contain arbitrary data. For directory nodes, its content is modified only indirectly as a result of a subtree deletion, node insertion, subtree move, or attribute modification.

6. Access: The content of the node is retrieved from the file system. This function does not change the file system as the other functions do.

An operation op can be denoted by a tuple op ⁼ <path, functions where the path may identify an existing node in the file system, and the functions may refer to one or more of the functions as defined the above, including required parameters. It can be assumed that the operations (functions) that change a file system can only be performed sequentially.

An event system 201 of a file system may be a source of a sequence of events, which may be configured so that events are generated as and when the file system is changed in specific ways. Each event e can be a tuple e = <path, type, data> where the path of the event refers to the path of a node in the file system that is relevant to the event. The data refers to auxiliary data that is associated with the event. The type of the event can be one of the following possible values:

1. Insert: This event may be generated after a node insertion, or a subtree move. For node insertion, the event path can be the path of the parent of the new node. For subtree move, the event path can be the path of the destination parent of the subtree after the move. In both cases, the event data contains the name of the new child of the node identified by the path.

2. Delete: This event may be generated after a subtree deletion, or a subtree move. The path of the event identifies the path of a node in the subtree before the move or delete.

3. ModifyContent: This event may be generated after file system operations that leads to changes of the file system node content. For subtree deletion, the path refers to the parent node of the subtree deleted. For node insertion, the path refers to the parent of the new node. For subtree move, two ModifyContent events may be generated, one with path identifying the parent of the subtree before the move, and the other identifying the parent of the subtree after the move. In all cases, the event data contains information that indicates which of the above operations generated the event.

4. Modify Attribute: This event can be generated when the attribute of a node is modified.

5. Preopen: This event may be generated before the content access and content modification operations happen upon a file node in the file system. The path can identify the node being accessed or modified, and the event data indicates if the operation is to access or to modify the node content.

There may be other types of events generated from the event system 201. The event system 201 can be configured by the policy engine to generate a subset of all possible events that may be generated. The event configuration (C) is in the form of a set of tuples of the form c = <path, types> where types is a set of types listed above, and the path must be the path of an existing node of the file system at the time when the configuration is made effective. A configuration c with a path that does not identify any existing node in the file system is considered invalid.

When a preopen event occurs, the intended file system node function is suspended until a response is sent by the policy engine to the event system 201. The operation can be either allowed or denied depending on the response. The following functions can be defined, which can be applied by the policy engine as a response to a preopen event.

1. Allow(event): This may tell the file system that the intended node function as indicated by the event is allowed.

2. Deny(event): This may tell the file system that the intended node function as indicated by the event is not allowed. As a result, the node function will not be applied to the file system.

In the following, optional aspects of the concept of a security policy 105 are defined in more detail.

A security policy P (e.g., the security policy 105) can be regarded as a set of rules, where each rule r (e.g., the rule 104) in P is a tuple r = <path, class, actions where the rule path may refer to a node in the file system that may or may not exist at the time the rule is effective. The rule class can be one of the following:

1. Create: A rule 104 of this class can be enforced when a node identified by the path appears in the file system but did not exist when the rule was made effective. Such scenarios may arise when the file system is changed by node insertion or subtree move.

2. Update: A rule 104 of this class can be enforced when the content of an existing node in the file system identified by the path is modified. For a file node, this refers to changes in the file content. For a directory node, this refers to changes in the list of files and directories under this node. In other words, inserting new nodes or removing existing nodes under the directory node would match this class.

3. Open: A rule 104 of this class can be enforced when a node in the file system identified by the path is to be accessed (read) or modified (written).

The rule actions can be a set of actions that should be taken when the rule 104 is enforced according to the path and the class, and may be one of the following:

1. Revert: The changes to the file system can be reverted.

2. Intercept: The operations to the file system can be prevented before it happens.

3. Others: Other actions that may be needed. For example, file system operations that trigger the rule 104 may be logged and reported for further analysis.

In the following, optional aspects of a rule basis are described in more detail. To allow the enforcement of policy rules 104, the policy engine can configure the event system 201 to receive relevant events. The rule basis for a specific policy rule 104 and a file system FS can be defined as an event configuration 202 and a file system operation that allows the rule enforcement given the current state of the file system. More formally, a rule basis b can be denoted by a tuple b = <r, path, types, functions where r is a reference to the rule 104 from which the basis is computed, types are the event types that should be received at the path (i.e., <path, types> is a valid event configuration as defined earlier), and functions is a set of file system functions to be applied to the file system at the path (i.e., <path, functions> is a file system operation).

A rule basis b is minimal, if for any other rule basis b ’ for the same rule r, the cardinality of b.functions is no more than b ’.functions (i.e., \bfunctions\ < \b ’.functions'^, and for b ’ where \bfunctions\ = \b '.f nctions^ the cardinality of b.types is no more than b ’.types (i.e., \b.types\ < \b ’.types\). In other words, a rule basis b is minimal if it first minimizes the number of required file system functions and then minimizes the number of events.

Given a rule basis b and an event configuration c, c may 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 basis b and a file system operation op, op may 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. a policy configuration can be defined as the tuple <B, C, O>, where B can be a set of rule basis for all the rules 104 in the policy 105, C can be a set of valid event configurations, and O can be a set of file system operations. A policy <B, C, O> is sound if for each rule basis b in , there exists an event configuration c in C and a file operation op in O such that b is covered by c and op. A sound policy <B, C, O> is minimal if every rule basis b in is minimal, and for any other sound policy <B C’, O ’>, |C| < |C’| and |( | < |( ’|.

In the present disclosure, three algorithms are designed as described next. The first algorithm RuleBasis can compute the basis for a rule 104 in a given policy 105 and a file system. The second PolicyConfig can compute the event configuration C and a set of operations from a policy P and a file system FS, and the third ConfigUpdate can compute a new configuration C ’ and operation O ’ when the policy or the file system has been changed.

The algorithms should satisfy the following property:

Property 1 (soundness): At any time, for the current policy P and file system FS, the policy configuration <B, C, O> computed by PolicyConfig and ConfigUpdate should always be sound.

The algorithms should further satisfy a second property:

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

To compute the rule basis given a rule r (i.e., the rule 104) in policy P (i.e., security policy 105) and a file system FS, first a path cursor for each rule r can be computed as follows: Each cursor = <index, path> may contain an index that indicates the number of path names in the rule 104 that are not matched to existing nodes in the file system, and a longest matched path that identifies an existing node in the file system.

RuleCursor(r, FS):

1. .s <- r. path, size - 1

3. fsnode nil 4. For z in 0, 1, 5

5. Find a directory node n in FS such that n.path = r.path[0, i]

6. If n is not nil

9. Else

10. Break For

11. End If

12. End For

13. If index > 0 and fsnode is not a directory node

15. fsnode fsnode. par ent

16. End If

17. Return <index, fsnode. path>

The notation list[O, i] denotes a slice of the list that contains the first i+1 elements. A path can be a list of names. Hence a slice of the path of a node may identify an intermediate node from the root to the node. The purpose of the RuleCursor is to know the longest prefix of the rule path that has a corresponding node in the file system. A cursor with an index of 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 enforce the rule.

With the above algorithm as a building block, a required configuration and file system changes for the rule r can be computed as follows. Each rule basis is a tuple that contains a reference to the rule from which it was generated, a path that identifies an existing node in the file system, a set of event types and a set of functions to be performed to the file system at the path.

RuleBasis(r, FS): or(r, FS

3. types - empty set

4. functions empty set

5. If cursor. index == 0

6. If r. class == Update 7. types { Modify Attribute }

8. functions = { Modify Attributes(-write) }

9. Else If r. class == Open

10. Preopen }

11. End If

12. Else (i.e,. cursor. index > 0)

13. Insert }

14. End If

15. Add Delete to types

16. Return <r, path, types, functions

The Modify Attributes function refers to the operation that changes the attributes of a node at the given path. Note that for a rule basis b, the tuple <b.path, b.types> forms a valid event configuration and the tuple <b.path, b.functions> forms a file system operation.

In a set of rule bases for the rules 104 in a policy 105, first the smallest event configuration set required can be determined. This can be achieved using the following algorithm.

EventConf(A< .s/.s) :

1. C <- empty set

2. For each b in basis

3. If b. types is empty

4. Continue

5. End If

6. Find c in C such that c.path = b.path

7. If c is nil (i.e., such a c is not found)

8. Add <b.path, b.types> to C

9. Else

10. Add b. types to c. types

11. End If

12. End For

13. Return C Similarly, a set of file system operations required by the given basis can be computed:

F SOperat ions(A< .s/.s) : empty set

2. For each b in basis

3. If b. functions is empty

4. Continue

5. End If

6. Find op in O such that op.path = b.path

7. If op is nil

8. Add b. operation to operations

9. Else

10. Add b. operation.functions to op. functions.

11. End If

12. End For

13. Return operations

Now the policy configuration required for a given file system FS and a policy P is computed as follows. Each policy configuration can be a tuple that contains the rule basis for all the rules, a set of event configurations required to configure the event system, and a set of file system operations to be applied to the file system.

PolicyConfig(P, FS)

1. empty set

2. For each rule r in P

3. b <- RuleBasis(r, FS

4. Add b to basis.

5. End For

6. eventConf EventConf(basis)

7. operations FSOperationsfAa.s/.s)

8. Return <basis, eventConf operations>

After a policy configuration is generated, the policy engine may then perform these file system operations and configure the event system using the event configurations. If the update of the policy configuration is caused by a change of the policy 105, a new configuration can be obtained by using the PolicyConfig algorithm in the above. Optimization is possible if most of the rules remain the same and only a small fraction of the rules 104 is changed. For example, it would be possible to first compute the difference of the policy rules, and then process only the differences.

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, it may be required to reconfigure the event system and perform necessary operations to the file system for the policy to be enforced. 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 has occurred.

UpdateConfig(e, C, P, FS) empty set

2. If e.type = Preopen

3. Deny(e)> }

4. Return <C. basis, C. eventConf, operations>

5. Else If e.type = Update (i.e., attribute change)

6. { <e.path, { Modify Attributes(-write) }> }

7. Return <C. basis, C. eventConf, operations>

8. End If

9. Find a subset of the basis B = { b in C.basis | b.path = e.path }.

10. B* - C.basis \ B (i.e., B* is now a subset that remains unchanged)

11. If e. type = Delete

12. any of B

13. RuleCursor(Z>.r, FS)

14. For each b in B

15. b.path cursor.pathj

16. End For

17. Else If e.type = Insert

18. For each b in B

19. cursor RuleCursor(Z>.r, FS) 20. If cursor, index = 0 and b.r. class = Create

21. operations { <e.path, { Remove }> }

22.

23. cursor.path.removeLast (i.e., remove the last element of the path list)

24. End If

25.

26. End For

27. End If

28. basis B* + B (i.e., original basis with updated cursors)

29. eventConf EventConf(A< .s/.s)

30. Return <basis, eventConf, operations>

In case the Preopen events are not supported by the underlying file system, similar to variations of the RuleBasis algorithm as discussed earlier, it can be checked if the event refers to a change of node attribute. If the attributes are changed and the rule class is Open, file operations need to be added to remove both the read and write attributes.

An operating scenario of the device 100 is now going to be described in view of FIG. 3. It is assumed that there is a system service “Live-Patch Manager” hosted on a target operating system, this service can be responsible for providing the initial security policy rules 104 and subsequent updates. It is further assumed that there is a second system service “Policy Engine” hosted on the same operating system that is responsible for enforcing such security rules. The overall system implementation is illustrated in FIG. 3.

As it is illustrated, after a security policy is initially configured or subsequently updated, the policy engine can first compute (or re-compute) the rule basis, from which a policy configuration is generated. The file system operations are performed, and the event system is configured or re-configured based on the policy configuration.

When an application 102 (in attempting to apply a live patch 101 to the application 102) tries to create, modify or access a file or directory, and if events are configured for the target path, such an event would be triggered by the file system and the event system. Upon receiving the event, the policy engine would update its current policy configuration, and reconfigure the file system and event system if needed. The UpdateEventSystem algorithm can be implementation specific, as will be described further below.

As described above, it can be shown that the algorithm to compute a rule basis for a given policy rule and the current file system is correct. In other words, for a rule basis b = <r, path, types, functions>, the event configuration <b.path, b.types> and the file system operation <b.path, b.functions> are sufficient to support the enforcement of the rule r.

Lemma 1 (RuleBasis): The rule basis <r, path, types, functions> computed by algorithm RuleBasis for rule r and file system FS is always sufficient and minimal.

Next, for each policy configuration <B, C, O> computed from a PolicyConfig algorithm given a policy and the current state of a file system, it can be shown that it is always sound and minimal according to the definitions given earlier. This means that the event configurations and file system operations are sufficient to enforce all the policy rules given the current state of the file system, and that the file operations and events are minimized.

Lemma 2 (PolicyConfig): The configuration computed by PolicyConfig is always sound and minimal.

Lastly, the soundness of the configuration update algorithm (ConfigUpdate) requires that the modified policy configuration is sound and minimal.

Lemma 3 (ConfigUpdate): The new policy configuration <B, C, O> computed by ConfigUpdate is always sound and minimal with respect of the file system after an event occurs.

In this section, a way to implement the abstract algorithms is described, using the inotify and fanotify APIs in a Linux-based system.

Since the abstract file system may follow a real Linux file system, the file system operations such as changing file attributes can be mapped directly to corresponding chmod function, and removing files and directories can be mapped to calls to nftw and remove functions, assuming the implementation is in the C language with the standard library. When both inotify and fanotify are available on the target operating system, the event configurations can be mapped to actual API calls as follows:

First, the only configuration that requires fanotify is the Preopen events, where a mark of type FAN OPEN PERM would be added to the corresponding path. The rest of the events are implemented as inotify watch points with proper masks, where Insert is mapped to (IN CREATE | IN MOVED TO), Delete is mapped to IN DELETE SELF, and Modify Attribute is mapped IN ATTRIB.

Furthermore, during policy update, the following steps are followed to translate changes in event configuration from EC to EC ’ to corresponding inotify and fanotify API calls.

UpdateEvent System! AC, EC ’)'.

1. For each c in EC

2. Find c ’ in EC ’ such that c.path = c ’.path

3. If c ’ is nil (i.e., configuration with the same path is not found)

4. Restore node attribute if c.types contains Modify Attribute

5. Remove inotify watch point at c.path, if c.types contains Insert, Delete or Modify Attribute

6. Unmark c.path with fanoitify if c.types contains Preopen

7. Else (i.e., the path still exists in the new configuration)

8. If c. types differs from c ’. types

9. Restore node attribute if c.types contains Modify Attribute but c ’.types does not

10. Adjust inotify watch point if needed

11. Mark/unmark fanoitfy path if needed

12. End If

13. End If

14. End For

15. For each c ’ vnEC’

16. Find c in EC such that c.path = c ’.path

17. If c is nil (i.e., new configuration path) 18. Add inotify watch points at c ’.path if c ’. types contains Insert, Delete or Modify Attribute

19. Mark fanotify at c ’.path if c types contains Preopen

20. End If

21. End For

Another important consideration during an actual implementation of the abstract algorithm is to handle concurrent changes to the file system. Since our algorithms assume that the changes and events in the file system and the event system are always in sequence, there are scenarios where the algorithms may fail due to concurrent changes. For example, when an application creates a new directory that matches part of the path of a rule 104, it is supposed to add a new inotify watch point for the directory according to the algorithms. However, if yet another directory is created under this new directory before the watch point can be added, it would have missed this directory creation event, which would lead to inaccurate execution. One way to handle such a scenario is to periodically re-run the RuleBasis algorithm to check for any inconsistencies between the actual file system and the already computed rule basis. Another option is to schedule a delayed basis computation whenever a new directory is created that matches a rule path.

For the abstract models and algorithms to be useful in general, scenarios need to be considered where the file system or the event system differ from the previous embodiment. For example, in some Linux-based systems, the fanotify API may not be available. In this case, the Preopen events will not be available in the event system. In this case, the Preopen event configuration can be mapped to file system operations that remove all access flags of the file and set an inotify watch point to watch for attribute changes instead. In this way, the target file effectively cannot be opened by the application.

In another example, if these algorithms shall be implemented in a very different operating system, such as Microsoft Windows, first it has to be developed an event system using Windows file system filter drivers, which would mimic the behavior of inotify and fanotify, before the first embodiment can be applied. It is also possible to develop other more effective APIs that allows easier mapping and processing. In another example, it is possible to modify the fanotify implementation so that the file open flags are passed to the policy engine so that it knows how the file was opened. In this case, instead of removing the writable flag on a file and watch for attribute changes, Preopen could be watched for events and deny access if the writable flag was present.

FIG. 4 shows a schematic view of a method 400. The method 400 is for securely applying a live patch 101 to an application 102 installed on a device 100. The method 400 comprises a first step of obtaining 401, by the device 100, a live patch 101 from a server. The method comprises a second step of determining 402, by the device 100, 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 in attempting to apply the live patch 101 to the application 102. The method comprises a third step of depending on the rule, prohibiting 403, by the device 100, the file system operation 103 from applying the live patch 101 to the application 102.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure, and the independent claims. In the claims as well as in the description, 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 fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.