WO2020182310A1

WO2020182310A1 - Method for implementing system state aware security policies

Info

Publication number: WO2020182310A1
Application number: PCT/EP2019/056399
Authority: WO
Inventors: Janne HÄMÄLÄINEN; Antti RUSANEN; Dmitry KASATKIN; Qiming Li; Gang LIAN
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2019-03-14
Filing date: 2019-03-14
Publication date: 2020-09-17
Also published as: CN112970021A; EP3915032A1

Abstract

A method and system for implementing system state aware Mandatory Access Control (MAC) on a computer-based system (10) by introducing a data collection module to collect real-time input data (3), a security service module that can determine the current system state based on the input data (3) and a set of predefined rules that enable the security service module to respond to a request of a subject (1) regarding an object (2) based at least partly on the current system state. The method further allows altering the system state, not only observing it.

Description

METHOD FOR IMPLEMENTING SYSTEM STATE AWARE SECURITY POLICIES

TECHNICAL FIELD

The disclosure relates to methods and systems for implementing security policies, more particularly for implementing Mandatory Access Control (MAC), on a computer-based system.

BACKGROUND

In computer security, Mandatory Access Control (MAC) refers to a type of access control by which the operating system constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In practice, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, 10 devices, etc. These subjects and objects each can have a set of security attributes, and whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any such attempt is tested against a set of authorization rules (also known as security policy) to determine if the operation is allowed.

In the case of MAC, the security policy is centrally controlled by a security policy administrator meaning end users do not have the ability to override the policy and, for example, grant access to files that would otherwise be restricted. By contrast, discretionary access control (DAC), which also governs the ability of subjects to access objects, allows users the ability to make policy decisions and/or assign security attributes.

In the past MAC has been closely associated with multilevel security (MLS) and specialized military systems. In such a context, MAC implies a high degree of rigor to satisfy the constraints of MLS systems. More recently, however, MAC started to appear outside of the military or MLS context. The more recent implementations for Linux and Windows operating systems allow administrators to focus on issues such as network attacks and malware without the rigor or constraints of MLS. However, these implementations carry different disadvantages and limitations.

SELinux, for example, is based on inodes that identify each file uniquely and require a file system which allows saving SELinux metadata to the files’ metadata structure. Therefore, it has a rather complex configuration syntax that makes it inaccessible for a standard user. TOMOYO Linux is based on declaring the behavior and resources needed by the process requesting the access. Furthermore, it is pathname-based, not metadata-label-based. Further examples are, amongst others: AppArmor, which is similar to SELinux but is based on file paths like TOMOYO Linux; and Smack, which is similar to SELinux, but intended to be simpler to configure by a standard user.

Typically, these solutions are based on some intermediary entity knowing both the party requesting for the access and the parties that are allowed to access e.g. a file in advance. This way, a static rule can be created which allows or denies access to a certain resource for a certain user. This approach works well in cases where the parties themselves are considered trusted or untrusted with regard to certain piece of data.

However, it falls short when e.g. a user inadvertently leaks data through deception or a mistake on a complex system.

Things get even more complicated if we consider a system of systems, for example, a computer network. If we consider separate systems, the access control is usually based on credentials of some sort, and an intermediary party needs to decide whether to allow the service request or now. Alternatively, there might be a firewall inspecting traffic and acting as a single point of control and making decisions on behalf of (or in addition to) the intermediary party. However, the decisions in these cases are typically also of static nature.

In fact, most of the prior art solutions are aimed at defining static rules. In individual cases, system state may be taken into account, but such a protection is implemented as a parallel mechanism where checking the system state is independent of the access control rules. This introduces possible race conditions when the state may change between evaluation of the state and later evaluation of the rule.

Furthermore, there are some methods that have some flexibility based on the nature of security classification data, e.g. the classification of data may be changed dynamically based on who has had access to it. However, this approach still does not address the problem of inadvertent user actions leading to security breaches of data. SUMMARY

It is an object to provide an improved method and system for implementing Mandatory Access Control (MAC) on a computer-based system that overcomes or at least reduces the problems mentioned above.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to a first aspect, there is provided a method for implementing Mandatory Access Control (MAC) on a computer-based system, the method comprising:

receiving a request from a subject for a function of the computer-based system, obtaining real-time input data regarding the state of the computer-based system, determining a current state of the computer-based system based on the real-time input data, and

responding to the request based at least in part on the current state of the computer-based system.

With the proposed method it becomes possible to introduce state awareness to a standard security policy language. Traditional mandatory access control systems don’t enable defining system state related factors that should limit accessing resources on a system. Introducing state awareness enables writing system state aware rules that allow specifying state related conditions for the rule, and these are considered when the rule is applied to the communication between processes or systems. This way applications and systems can be allowed to interact, but the communication can be temporarily disabled when the system state is such that it might compromise the confidentiality of the data. For example, communications could be prevented temporarily while the target system has sensitive data in memory. Alternatively, the rule can define what the system state should be in order to allow communication.

The approach is extensible and scalable with apps and threats and capabilities of the system. The method can further give security experts more tools when they define rules for a large set of devices. The security focus can expand from process-target resource permissions to the whole of the system state in which processes access resources.

Furthermore, the method is also user friendly, because even side-loaded applications can be allowed in the system while the security sensitive applications remain protected.

In a possible implementation form of the first aspect the function comprises at least one of accessing one or more objects of the computer-based system or

performing an operation on one or more objects of the computer-based system.

In a possible implementation form of the first aspect the one or more objects comprise at least one of

a file or a directory of a file system defined on a storage device of the computer-based system;

a part of an allocated memory area defined on a memory device of the computer-based system;

an application installed on the computer-based system;

a process running on the computer-based system;

a communication port of the computer-based system;

an input device of the computer-based system; or

an output device of the computer-based system.

By implementing the method for the above range of possible objects it becomes possible to improve the security of e.g. open software platforms such as Android, especially when considering security risks of applications that originate from outside of the trusted vendors. The method can further protect users from mistakes, e.g. if an otherwise approved application is collecting data from the system (like capturing the screen or reading logs or accessing other such sources), and the user switches to a security sensitive workflow which, combined with the current system state, might leak information indirectly to unauthorized processes.

In a possible implementation form of the first aspect the method further comprises defining a level of protection for at least one of the one or more objects, wherein the level of protection can be stored in the form of metadata associated with the at least one object.

By defining a level of protection for objects it becomes possible to implement rules that can differentiate not only between protected and non-protected objects, but also between protected objects of different security level and make decisions regarding access control based on e.g. assigned security classes of subjects. Storing the information in the form of associated metadata makes it possible to easily and quickly access the relevant information for making the access control decisions.

In a possible implementation form of the first aspect responding to the request is further based on the level of protection of the one or more objects.

With this implementation form it becomes possible to use a combination of system state input data and metadata regarding protection level to make more complex access control decisions.

In a possible implementation form of the first aspect the subject is one of

an application installed on the computer-based system;

a process running on the computer-based system; or

a computer device as a part of as a part of a distributed system of devices.

With this implementation form it becomes possible to give security experts more tools when they define rules for e.g. a large set of devices connected in a distributed system. It allows the security focus to expand from process-target resource permissions to the whole of the system state in which processes access resources.

In a possible implementation form of the first aspect the real-time input data comprises at least one of

current physical location;

current time and date;

list of currently installed applications on the computer-based system,

list of currently running processes on the computer-based system, wherein the processes may include recording of displayed information; list of currently logged on users on the computer-based system;

current class of operation of the computer-based system, wherein classes of operation may comprise business or personal use;

currently required security level on the computer-based system;

measurable physical circumstances of operation of the computer-based system;

information regarding network connection state in relation to physical circumstances of operation of the computer-based system;

state of a protected segment defined on a memory device of the computer-based system.

By implementing the method with the above range of possible real-time input data it becomes possible to determine the system state according to many factors and make informed access control decisions. For example, communications could be prevented temporarily while the target system has sensitive data in memory. Alternatively, a rule can define what the system state should be in order to allow communication. In a further example, communications could be prevented temporarily while the target system is in a physical (high security) location and allowed when the system leaves such a location. This implementation can in particular further protect users from mistakes, e.g. in case that an otherwise approved application is collecting data from the system through a screen capturing or keylogger process.

In a possible implementation form of the first aspect the method further comprises defining, before receiving the request, a set of MAC rules, the MAC rules comprising MAC conditions, wherein defining the MAC rules may require administrator privileges on the computer-based system;

wherein the set of MAC rules can be stored on a storage device of the computer-based system; and

wherein responding to the request is based at least in part on the set of MAC rules.

Defining a set of MAC rules with dedicated MAC conditions enable the system to make more complex decisions wherein system state can be taken account in a non-binary way. Tying the creation and editing of MAC rules to administrator privileges enables enforcing a more strict security wherein lower security level users cannot change how the system responds to control access requests in case of different system states. In a possible implementation form of the first aspect responding to the request comprises one of

allowing the function;

denying the function;

allowing the function if one or more of the MAC conditions are fulfilled; or

allowing the function after one or more of the MAC conditions are fulfilled.

Defining a set of MAC rules with dedicated MAC conditions in a way that the system state can be taken account in a non-binary way makes it possible to define a more flexible MAC method wherein the response of the system is not automatic denial in case one or more preset conditions are not fulfilled. This allows for further possibilities when designing system security policies that takes into account possible changes to the system state between two consecutive evaluations when deciding how to respond to a request.

This enhances usability, because instead of telling a user that a certain action is prohibited, the system state can be altered (by the user or on his behalf), an operation can be performed, and then the restriction can be lifted.

This way the rules can instruct a reference monitor (such as a Security Service Module) to disable launching certain applications at certain hours, preventing certain applications from working fully if the system has other than white-listed applications installed, or letting user to switch the phone in a mode where only a limited set of applications are allowed to run and communicate.

In a possible implementation form of the first aspect the method further comprises altering the current state of the computer-based system, and

responding to the request based at least in part on the modified current state of the computer-based system.

This implementation enables altering the system state before allowing communications to pass. For example, in case of recording of the screen, audio, or video signals this implementation could stop the recording process before allowing screen contents to change or media to play. In case of a remote service, it could request flushing the sensitive areas of memory of the target system before allowing communications to pass. The additional step thus enables many opportunities for flexibility of MAC in contrast to a static set of rules with binary allow/deny responses. This gives additional protection against user mistakes, e.g. in case an otherwise approved application is collecting data from the system (like capturing the screen or reading logs or accessing other such sources), and the user switches to security sensitive work flow which combined with the current system state might leak information indirectly to unauthorized processes. The method is also user friendly, because instead of denying access from e.g. a side-loaded application, it can be allowed in the system with certain restrictions to access to sensitive data. Thus, the security sensitive applications remain protected.

In a possible embodiment the method further comprises restoring the system state back to its original state as it was before the alteration.

In a possible implementation form of the first aspect altering the current state of the computer-based system results in fulfilling one or more predefined conditions of allowing the function.

This implementation enables making changes in the system state with the specific purpose to fulfill predefined (MAC) conditions, thus resulting in a dynamic interaction between the rules and the system state.

According to a second aspect, there is provided a computer-based system for implementing Mandatory Access Control (MAC), the system comprising at least a Data Collection Module (DCM) configured for obtaining real-time input data regarding the state of the computer-based system;

a processor; and

a storage device configured to store instructions that, when executed by the processor, cause the computer-based system to perform a method according to any one of the possible implementation forms of the first aspect.

Introducing a Data Collection Module (DCM) to the system enables to dedicate a specific hardware or software with allocated resources (e.g. processing power and memory) for collecting input data regarding the state of the computer-based system. Having a separate module also increases security and makes it easier to set up the multitude of possible input channels operated parallel to each other. In a possible implementation form of the second aspect, the system further comprises a Security Service Module (SSM), wherein the SSM is configured for

receiving a request from a subject for a function of the computer-based system, receiving the real-time input data regarding the state of the computer-based system from the DCM, and optionally further receiving at least one of metadata regarding a level of protection for one or more objects of the function, or a set of MAC rules comprising MAC conditions;

determining a current state of the computer-based system based on the real-time input data, and

responding to the request based at least in part on the current state of the computer-based system, and optionally in part on at least one of the metadata or the set of MAC rules.

Introducing a Security Service Module (SSM) to the system enables to dedicate a specific hardware or software with allocated resources (e.g. processing power and memory) for the tasks of evaluating the different input data and responding to the access control request. It enables hardening an application framework with additional security checks. The SSM can be in some regards similar to existing ones - be it part of a platform security system, a firewall, or other such single point of control -, that is, it has a policy that consists of rules; it identifies protected objects through their associated metadata; and it applies rules in decision making process. However, this approach introduces state awareness to the policy language in contrast to traditional MAC implementation systems that do not enable defining system state related factors that should limit accessing resources on a system.

In a possible implementation form of the second aspect the computer-based system is implemented on a computer device,

wherein the system further comprises an Inter Process Communication (IPC) module configured for exchanging data between applications running on the device;

wherein the SSM is configured to receive the request from the IPC module, and further configured to respond to the request to the IPC module.

Implementing the system on a single device makes it possible to improve security of the device by enabling an inter process module to control the communication between resources and processes of the same device. This way applications on the device can be allowed to interact, but the communication can be temporarily disabled when the system state is such that it might compromise the confidentiality of the data.

In a possible implementation form of the second aspect the computer-based system is implemented as a distributed system of multiple computer devices connected in a data network;

wherein the system further comprises a Traffic Controller (TC) module configured for monitoring all data exchange between the multiple computer devices;

wherein the SSM is configured to receive the request from the TC module, and further configured to respond to the request to the TC module.

Implementation of the process on a system of multiple computer devices connected in a data network makes it possible to improve security on distributed systems by enabling a traffic controller module to control the resources and processes of a target system. Thus, the traffic controller could ensure that the target system is in safe state before allowing traffic there.

These and other aspects will be apparent from and the embodiment(s) described below. BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present disclosure, the aspects, embodiments and implementations will be explained in more detail with reference to the example embodiments shown in the drawings, in which:

Fig. 1 illustrates in a flow diagram the core steps of the MAC implementation method in accordance with an embodiment of the first aspect.

Fig. 2 is a flow diagram of defining a level of protection for objects in accordance with another embodiment of the first aspect.

Fig. 3 is a flow diagram of the MAC implementation method in accordance with another embodiment of the first aspect. Fig. 4 is a flow diagram illustrating possible types of subjects and objects in accordance with another embodiment of the first aspect.

Fig. 5 is a flow diagram of illustrating possible types of input data in accordance with another embodiment of the first aspect.

Fig. 6 is a flow diagram of defining and saving a set of MAC rules in accordance with another embodiment of the first aspect.

Fig. 7 illustrates an exemplary set of MAC rules in accordance with another embodiment of the first aspect.

Fig. 8 is a flow diagram illustrating the different possibilities of responding to an incoming request in accordance with another embodiment of the first aspect.

Fig. 9 is a block diagram illustrating a computer-based system in accordance with an embodiment of the second aspect.

Fig. 10 is a block diagram illustrating a computer-based system in accordance with another embodiment of the second aspect.

Fig. 1 1 is a block diagram illustrating the components of a computer device in accordance with another embodiment of the second aspect.

DETAILED DESCRIPTION

In a first step 101 , a request is received from a subject 1 for a function of the computer- based system 10. The steps of the method relate to implementing Mandatory Access Control (MAC) on a computer-based system 10 to control the access of a subject to a function of the computer-based system 10. This function can be either access to or generally performing some sort of operation on an object 2. The possible types of objects and subjects in this context are explained below in connection with Fig. 4. In a next step 102, real-time input data 3 regarding the state of the computer-based system 10 is obtained. The possible types of objects and subjects in this context are explained below in connection with Fig. 5.

In a next step 103, the current state of the computer-based system 10 is determined based on the real-time input data 3. Depending on the type of input data this system state can refer to many different circumstances, e.g. whether an otherwise approved application is collecting data from the system (like capturing the screen or reading logs or accessing other such sources).

In a next step 104, a response is generated to the request based at least in part on the current state of the computer-based system 10. This can mean, in the example above, that the system denies access of another application to the display device as long as the data collection is ongoing, as it might leak information indirectly to unauthorized processes.

Fig. 2 is a flow diagram of defining a level of protection for objects in accordance with another embodiment of the first aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In a first step 201 , a level of protection for at least one of the one or more objects 2 is defined. In one embodiment this level of protection can be a simple binary attribute, such as protected or non-protected. In another embodiment there are multiple protection levels within the protected range. In one embodiment, responding to the request 104 for a function of the computer-based system 10 is based on - in addition to the real-time input data 3 - the level of protection assigned in this step.

In a next, optional step 202, the information regarding the level of protection is stored in the form of metadata 4 associated with the at least one object 2. In one embodiment this metadata 4 is saved on a storage device 13 of the computer-based system 10 so that it can be easily and quickly accessed when making the decision regarding the response to the request 104. Fig. 3 illustrates on a flow diagram two possible MAC implementation methods in accordance with further embodiments of the first aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In an embodiment illustrated as a possibility on Fig. 3 after responding to the request 104, the allowed function is accessing 1041 one or more objects 2 of the computer-based system 10. In another embodiment the requested and allowed function is performing an operation 1042 on one or more objects 2 of the computer-based system 10.

Fig. 4 is a flow diagram illustrating possible types of subjects and objects in accordance with another embodiment of the first aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In a first step of the flow diagram the possible types of subjects are illustrated, such as: an application 5 installed on the computer-based system 10; a process 6 running on the computer-based system 10; or a computer device 20 as a part of a distributed system 22 of devices.

In the next steps 102 to 104 real-time input data 3 is obtained, the current state of the computer-based system 10 is determined, and a response is generated 104 to the incoming request. This response can be a denial that is then sent back to the subject, or allowance of access/operation on a list of objects illustrated, such as: a file or a directory of a file system 7 defined on a storage device 13 of the computer-based system 10; a part of an allocated memory area 8 defined on a memory device 1 1 of the computer-based system 10; an application 5 installed on the computer-based system 10; a process 6 running on the computer-based system 10; a communication port 16 of the computer- based system 10; an input device 14 of the computer-based system 10; or an output device 15 of the computer-based system 10.

Fig. 5 is a flow diagram of illustrating possible types of input data in accordance with another embodiment of the first aspect. The input data can represent different kinds of information regarding the system state in real-time, as illustrated by exemplary pictograms, such as: current physical location of a device 20; current time and date; a list of currently installed applications 5 on the computer-based system 10; a list of currently running processes 6 on the computer-based system 10, particularly whether there is a process recording any displayed information; a list of currently logged on users on the computer-based system 10; the current class of operation of the computer-based system 10 (this may comprise e.g. business or personal use); the currently required security level on the computer-based system 10; any measurable physical circumstance of operation of the computer-based system 10; information regarding network connection state in relation to physical circumstances of operation of the computer-based system 10; or the state of a protected segment defined on a memory device 1 1 of the computer-based system 10.

The input data is collected by a Data Collection Module (DCM) 18 and then sent to a Security Service Module (SSM) 19 that is configured to receive different types of further possible input information, such as metadata 4 regarding a level of protection for one or more objects 2 of the function, or a set of MAC rules 9 comprising MAC conditions (see more in detail below) and to determine a current state of the computer-based system 10 and respond to the incoming request.

Fig. 6 is a flow diagram of defining and saving a set of MAC rules 9 in accordance with another embodiment of the first aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In a first step, before receiving the request, a set of MAC rules 9 are defined. These MAC rules 9 comprise MAC conditions that will be explained in detail below.

In one embodiment defining the MAC rules 9 requires administrator privileges on the computer-based system 10 in a next step, which in turn enables enforcing a stricter security wherein lower security level users cannot change how the system responds to control access requests in case of different system states.

In a next, optional step 302, the set of MAC rules 9 are stored 302 on a storage device 13 of the computer-based system 10. This enables the Security Service Module (SSM) 19 to take into account the MAC rules and conditions when responding to the incoming request. Fig. 7 illustrates an exemplary set of MAC rules in accordance with another embodiment of the first aspect.

The MAC rules are defined according to a rules language to work together with a reference monitor (such as the Security Service Module 19) that can monitor also the system state in addition to enforcing the rules. This combination allows the rules to define in which condition the rule may be applied. Rules are similar to the rules used in other Mandatory Access Control systems, but with a few exceptions or additions.

The rules can be defined in a rule table where the columns represented are as follows. ‘DECISION’ refers to the control access response determined by the reference monitor. ‘SUBJECT’ can refer to a unique subject 1 (in one specific implementation it is the package name of an application 5 or process 6, e.g. "com.huawei.applicationABC") or a group of subjects 1 . There can be any number of groups, and the groups are formed from the label(s) associated with the application 5 in the policy definition.‘ANY’ is a hard-coded wildcard and in the example refers to group of all possible subjects 1 .

The same applies to OBJECT’, where it can be a group or it can be an unique identifier of the target of an inter-process call.‘SENSITIVE’ in the examples is a group of packages that have a‘SENSITIVE’ label associated with them in the policy.

In an embodiment multiple levels of protection can be defined within the‘SENSITIVE’ label.

The separation of ‘SUBSYSTEM’ and OPERATION’ enables defining rules that apply to ANY operation in some subsystem, or more specific rules for some operations, e.g. ‘SEND’ operation in‘INTENT’ subsystem in the exemplary Android case.

‘SUBSYSTEM PARAMETER’ is a feature of the policy language. It enables writing more fine-grained rules for a subsystem. For example, if there is a‘SEND’ operation in the ‘INTENT’ subsystem, and a subject 1 is sending data to an object 2, it enables writing rules based on types of data or amount of data associated with the send operation.

The‘ALLOWIF CONDITION’ works as follows: a system or a system service that passes messages (e.g. Binder framework passing intents in Android, or a firewall in a network) consults a reference monitor (such as the SSM 19) every time a message passes through it. In alternative embodiments, it can be a reference monitor itself that passes the messages, if that is preferred for performance or other reasons. The reference monitor then either allows or denies the message to the target object according to the rules regarding the messaging between the two, and after considering also the system state. If the “Allowlf” condition is passed, the communication can proceed. If not, then it is prevented.“Allowif” can be based on measurements the system, but it can be also based on time of the day or other such factors, as listed above in reference to Fig. 5.

The‘ALLOWAFTER CONDITION’ works in similar manner, but it can additionally instruct the reference monitor to adjust the system state (at least) for the duration of the messaging. Thus, in addition to telling the reference monitor to check the system state, the rules can advise the reference monitor what system state would be suitable. This enhances usability, because instead of telling the user that a certain action is prohibited, the system state can be altered on user’s behalf, an operation can be performed, and then the restriction can be lifted. Possibly system state could also be restored back to what it was before a protected operation was performed.

In the exemplary embodiment illustrated on Fig.7 the MAC rules are defined so as to prevent screen recording of sensitive applications.

The first four rows belong to the first group of MAC rules that handle stopping the screen recording process when starting sensitive application by sending intent to it.

This group comprises two MAC conditions. An ‘ALLOWIF’ condition defined as “ScreenRecording=false” means only allowing starting of the sensitive application IF there is no screen recording process running. An additional‘ALLOWAFTER’ condition defined as “actio StopScreenRecording, condition:ScreenRecording=false” means stopping the screen recording process when starting a sensitive application, and only allowing it once the there is no screen recording process detected.

The fifth and sixth row belong to the second group of MAC rules that handle preventing the starting of a screen recording process while a sensitive application is visible. Fig. 8 is a flow diagram illustrating the different possibilities of responding to an incoming request in accordance with another embodiment of the first aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In step 102 the SSM 19 obtains the input data 3 from the DCM, as well as the MAC rules 9 and optionally the metadata 4 from the storage device 13.

After defining the system state 103 responding to the request 104 can happen in different alternative ways based on the MAC conditions and the determined system state.

In a possible scenario the rules are checked in relation to the system state (and metadata 4) and the function is either allowed 401 or denied 402.

In another possible scenario the MAC rules 9 are checked in relation to the system state (and metadata 4) and the function is either denied 402 or allowed 403 in case one or more of the MAC conditions are fulfilled.

In another possible scenario the MAC rules 9 are checked in relation to the system state (and metadata 4) and the function is either denied 402 or allowed after 404 one or more of the MAC conditions are fulfilled (with a delay). In an embodiment the state of the computer-based system 10 is altered 501 and and fulfillment of the MAC rules 9 is checked again to determine the response 502 to the request based at least in part on the modified state of the computer-based system 10.

Fig. 9 is a block diagram illustrating a computer-based system 10 implemented on a computer device 20 in accordance with an embodiment of the second aspect.

A component in the system 10 called Data Collection Module (DCM) 18 collects input from a set of predefined sources. The device 20 is configured to support this kind of data collection. These input data can be measurements of the system state, time of the day, currently logged on user, and other such input categories that need to be included in a predefined set of MAC rules 9. A system administrator defines these MAC rules 9 and can use the input categories and set target values for those as part of the rules. The decision of a rule can then be conditionally applied, and the decision is based on system state.

The system 10 further comprises a Security Service Module (SSM) 19 through which all of system messaging passes. This can be a new module implemented as an addition to the system 10, or as an extension of an existing module. This SSM 19 takes MAC rules 9 as an input, and the input data 3 from the DCM 18 like state of screen capturing, time of the day, list of installed applications, and any other additional sources that may be relevant to deciding if the system is safe or not. The SSM can further take as input metadata 4 regarding protection level of objects 2.

The system 10 further comprises an Inter Process Communication (IPC) module 21 configured for exchanging data between applications 5a, 5b loaded into a memory 1 1 on the computer device 20. The IPC module 21 is configured to send any request originating from one application 5a concerning a function of another application 5b to the SSM 19. After obtaining all the inputs, the SSM 19 inspect the rules concerning the current request and either allows or denies it, or allows the request if certain conditions are fulfilled, or allows the request after certain conditions are fulfilled.

Fig. 10 is a block diagram illustrating a computer-based system 10 implemented as a distributed system 22 of multiple computer devices 20a, 20b, 20c connected in a data network in accordance with another embodiment of the second aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

In this embodiment the system 10 for MAC implementation is configured as an intermediary device 20c between a source device 20a acting as subject 1 and a target device 20b acting as object 2.

A component in the system 10 called Data Collection Module (DCM) 18 collects input from a set of predefined sources. The devices 20a, 20b, 20c are configured to support this kind of data collection. These input data can be the state of a protected memory segment on the target device 20b, time of the day, currently logged on user on the target device 20b, processes running on target device 20b, and other such input categories that need to be included in a predefined set of MAC rules 9. A system administrator defines these MAC rules 9 and can use the input categories and set target values for those as part of the rules. The decision of a rule can then be conditionally applied, and the decision is based on system state.

The system 10 further comprises a Traffic Controller (TC) module 23 configured for monitoring all data exchange between the computer devices 20a, 20b, 20c. The TC module 23 is further configured to send any request originating from one application 5a on the source device 20a concerning a function of another application 5b on the target device 20b to the SSM 19.

After obtaining all the inputs, the SSM 19 inspect the rules concerning the current request and either allows or denies it, or allows the request if certain conditions are fulfilled, or allows the request after certain conditions are fulfilled.

Fig. 1 1 is a block diagram illustrating the components of a computer device 20 comprising a computer-based system 10 in accordance with another embodiment of the second aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

The computer device 20 may comprise a processor (CPU) 12 configured to execute instructions that cause the computer-based system 10 to perform a method according to any of the possible embodiments above. The computer device 20 may also comprise a storage medium (HDD) 13 (HDD) for storing input data 3, metadata 4, MAC rules 9, and software-based instructions to be executed by the CPU 12.

The computer device 20 may also comprise a memory (RAM) 1 1 configured for (temporarily) storing data of applications 5, 5a, 5b and processes 6.

The computer device 20 may also comprise a Data Collection Module (DCM) 18 configured for obtaining real-time input data 3 regarding the state of the computer-based system 10.

The computer device 20 may also comprise a Security Service Module (SSM) 19 configured for receiving a request from a subject 1 for a function of the computer-based system 10, receiving real-time input data 3 regarding the state of the computer-based system 10 from the DCM 18, and optionally further receiving at least one of metadata 4 regarding a level of protection for one or more objects 2 of the function, or a set of MAC rules 9 comprising MAC conditions; determining a current state of the computer-based system 10 based on the real-time input data 3, and responding to the request based at least in part on the current state of the computer-based system 10, and optionally in part on at least one of the metadata 4 or the set of MAC rules 9.

The computer device 20 may also comprise an IPC module 21 configured for exchanging data between applications 5 running on the computer device 20. Alternatively, if computer- based system 10 is implemented as a distributed system 22 of multiple computer devices 20a, 20b, 20c connected in a data network, the computer device may comprise a Traffic Controller (TC) module 23 configured for monitoring all data exchange between the multiple computer devices 20a, 20b, 20c.

The computer device 20 may further comprise an input device (IN) 14 for receiving input from a user, an output device (OUT) 15 such as an electronic display for conveying information to a user, and a communication interface (COMM) 16 for communicating with external devices directly, or indirectly via a computer network.

The mentioned hardware elements within the computer device 20 may be connected via an internal bus 17 configured for handling data communication and processing operations. The various aspects and implementations has been described in conjunction with various embodiments herein. However, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed subject-matter, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word“comprising” does not exclude other elements or steps, and the indefinite article“a” or“an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

The reference signs used in the claims shall not be construed as limiting the scope.

Claims

1 . A method for implementing Mandatory Access Control, MAC, on a computer-based system (10), the method comprising:

receiving (101 ) a request from a subject (1 ) for a function of said computer-based system (10),

obtaining (102) real-time input data (3) regarding the state of the computer-based system

(10),

determining (103) a current state of the computer-based system (10) based on said real time input data (3), and

responding (104) to said request based at least in part on the current state of the computer-based system (10).

2. A method according to claim 1 , wherein said function comprises at least one of accessing (1041 ) one or more objects (2) of said computer-based system (10) or performing an operation (1042) on one or more objects (2) of said computer-based system (10).

3. A method according to claim 2, wherein said one or more objects (2) comprise at least one of

a file or a directory of a file system (7) defined on a storage device (13) of said computer- based system (10);

a part of an allocated memory area (8) defined on a memory device (1 1 ) of said computer- based system (10);

an application (5) installed on said computer-based system (10);

a process (6) running on said computer-based system (10);

a communication port (16) of said computer-based system (10);

an input device (14) of said computer-based system (10); or

an output device (15) of said computer-based system (10).

4. A method according to any one of claims 2 or 3, further comprising

defining a level of protection (201 ) for at least one of said one or more objects (2), wherein said level of protection can be stored (2021 ) in the form of metadata (4) associated with said at least one object (2).

5. A method according to claim 4, wherein

responding to said request (104) is further based on said level of protection of said one or more objects (2).

6. A method according to any one of claims 1 to 5, wherein said subject (1 ) is one of an application (5) installed on said computer-based system (10);

a process (6) running on said computer-based system (10); or

a computer device (20) as a part of a distributed system (22) of devices.

7. A method according to any one of claims 1 to 6, wherein said real-time input data (3) comprises at least one of

current physical location;

current time and date;

list of currently installed applications (5) on said computer-based system (10), list of currently running processes (6) on said computer-based system (10), wherein said processes (6) may include recording of displayed information;

list of currently logged on users on said computer-based system (10);

current class of operation of said computer-based system (10), wherein classes of operation may comprise business or personal use;

currently required security level on said computer-based system (10);

measurable physical circumstances of operation of said computer-based system (10); information regarding network connection state in relation to physical circumstances of operation of said computer-based system (10);

state of a protected segment defined on a memory device (1 1 ) of said computer-based system (10).

8. A method according to any one of claims 1 to 7, further comprising

defining (301 ), before receiving said request, a set of MAC rules (9), said MAC rules (9) comprising MAC conditions, wherein defining said MAC rules (9) may require administrator privileges on said computer-based system (10);

wherein said set of MAC rules (9) can be stored (302) on a storage device (13) of said computer-based system (10); and

wherein responding to said request (104) is based at least in part on said set of MAC rules (9).

9. A method according to claim 8, wherein responding to said request comprises one of allowing (401 ) said function;

denying (402) said function;

allowing said function if (403) one or more of said MAC conditions are fulfilled; or allowing said function after (404) one or more of said MAC conditions are fulfilled.

10. A method according to any one of claims 1 to 9, further comprising

altering the current state (501 ) of the computer-based system (10), and

responding (502) to said request based at least in part on the modified current state of the computer-based system (10).

1 1 . A method according to claim 10, wherein

altering (501 ) the current state of the computer-based system (10) results in fulfilling one or more predefined conditions of allowing said function.

12. A computer-based system (10) for implementing Mandatory Access Control, MAC, the system comprising at least

a Data Collection Module, DCM (18), configured for obtaining real-time input data (3) regarding the state of the computer-based system (10);

a processor (12); and

a storage device (13) configured to store instructions that, when executed by said processor (12), cause the computer-based system (10) to perform a method according to any one of claims 1 to 1 1 .

13. A computer-based system (10) according to claim 12, further comprising a Security Service Module, SSM (19), wherein said SSM (19) is configured for

receiving a request from a subject (1 ) for a function of said computer-based system (10), receiving said real-time input data (3) regarding the state of the computer-based system (10) from said DCM (18), and optionally further receiving at least one of metadata (4) regarding a level of protection for one or more objects (2) of said function, or a set of MAC rules (9) comprising MAC conditions;

determining a current state of the computer-based system (10) based on said real-time input data (3), and responding to said request based at least in part on the current state of the computer- based system (10), and optionally in part on at least one of said metadata (4) or said set of MAC rules (9).

14. A computer-based system (10) according to claim 13, wherein the computer-based system (10) is implemented on a computer device (20),

wherein the system further comprises an Inter Process Communication, IPC, module (21 ) configured for exchanging data between applications (5) running on said computer device (20);

wherein said SSM (19) is configured to receive said request from said IPC module (21 ), and further configured to respond to said request to said IPC module (21 ).

15. A computer-based system (10) according to claim 13, wherein the computer-based system (10) is implemented as a distributed system (22) of multiple computer devices (20a, 20b, 20c) connected in a data network;

wherein the system further comprises a Traffic Controller, TC, module (23) configured for monitoring all data exchange between said multiple computer devices (20a, 20b, 20c); wherein said SSM (19) is configured to receive said request from said TC module (23), and further configured to respond to said request to said TC module (23).