The BLP model is originally designed for a traditional operating system environment. Taking into account the characteristics of virtualized environments and their differences from the traditional operating system environment, the PVME model applies the basic principles of the BLP model and adapts security axioms and state transition rules of the BLP model to accommodate for the virtual machine escape (mainly Hypervisor communication) scenario.
4.3.1. Model Elements
The PVME model uses the same symbols of the BLP model. The basic elements include: subject, object, access attribute set, main object security level, access control matrix, object level and system status. The following is a detailed description of the basic elements of PVME model.
Subject: the subject represents the active side that issues access operations and access requests. It usually refers the users or processes that can make the information flow. The capital S represents the subject set and the lowercase s represents a single subject, namely .
Object: the object represents the side that can be accessed, generally documents, procedures or equipment that can be called. The capital O represents the subject set and the lowercase o represents a single subject, namely .
Access Attribute Set: access set . In our research environment, the communicating parties involved Hypervisor, VM, QEMU and Guest OS. However the subject can only be Hypervisor or QEMU and the object can be Hypervisor, Guest OS, VM or QEMU. When a virtual machine communicates with the Hypervisor, in addition to traditional access modes (read-only (r), write-only (a), write-read (w)), we redefine the implementation of access mode (), and add a new access mode (). Since the execution () access in the BLP model is completely redefined in the PVME model, we use to make that distinction. The execution () and control () modes are the only two operations that exist when theHypervisor communicates with virtual machines. Therefore, the access attribute set .
Access Control Matrix: the element of access control matrix M represents the subject owns the access to the object in current state.
Security Level: the security level contains security classification and security category. denotes the security classification set where and represents the security category set whose element is a specific access property. Security level set is a partial ordered set, each item in the set represents a security level, which , , . If and only if then we get . Each element in security level vector set is where is the security level function of the object, is the security level function of the object and is the current security level function of the subject.
Object Hierarchy: object level set H indicates the subordinate relationship between subject and object. In the object hierarchy, a node mostly has one and only one parent without a hierarchy ring. The symbol represents is the leaf node and is the parent node in the hierarchy.
System Status: system Status collection is a four-tuple , every single element quadruple represents a system status, in which , , , are the current accessing set, access control matrix, security level vector set and the hierarchy of the objects, respectively. The symbol , and its element is the current access set, which records what subject can access what objects in which access property.
Request Element Set: request element set
, where the
denotes get or give the requests and the
denotes release or rescind the requests. The request set
, whose function is as shown
Table 1.
The related elements and corresponding access processes of the PVME model are based on a full virtualization platform. From bottom to top in
Figure 3: host OS represents the host operating system; Hypervisor represents the corresponding virtual machine monitor. Since the current mainstream virtual machine simulator is mostly based on QEMU, we use QEMU to represent the virtual machine simulator of the whole virtual architecture. Guest OS stands for the virtual machine operating system. In this architecture, VM is mainly used to express the whole QEMU and Guest OS.
The PVME model is designed to prevent virtual machine escape attacks in the virtualization system. As shown in
Figure 3, the hardware command issued by the Guest OS will be simulated by QEMU, and then was sent to Hypervisor as process ① and process ② show, and process ③, ④ represent the response to Guest OS’s hardware request. For virtual machine escape, we mainly prevent the attack from Guest OS to Hypervisor or hosts, without considering the impact of Hypervisor on the Guest OS. Therefore the PVME model combines process ③, ④ into process ⑤, which represents communication between VMs and Hypervisor. The PVME model mainly considers processes ①, ②, ⑤ in the full virtualized architecture.
The set includes subjects that meet with the * -property of BLP model, denotes the set of trusted subjects. The Hypervisor is used for managing other virtual machines on the host and has the absolute authority above the virtual machines. When Hypervisor is a subject, we define it as a trusted one and it belongs to the trusted set . In fact, Hypervisor is the only trusted subject. When Hypervisor is an object, it serves as the root node of the object set, namely . In this case, when the Guest virtual machines are objects, in the object hierarchy, they are child nodes of Hypervisor (the root), and are located in the same object hierarchy. Obviously, in the PVME model the object hierarchy maintains the two significant properties of the BLP model, i.e., in the object hierarchy, a node at most has one parent node, and there is no cycle in the object hierarchy.
4.3.3. State Transition Rules
The PVME model includes 9 state transition rules, denoted . The input is a (request, state) pair and correspondingly the output is a (result, state) pair, which is similar to the BLP model. The following is a brief introduction of some symbols used in the description of state transition rules.
In the input pairs, the form of the request is different in different rules, but the expression of the state is always . Therefore we only need to concern the request section of the rule’s domain (definitional domain). Accordingly, the rule’s domains are recorded as domain . In the output pairs, result is defined as the set , where yes means the request will be permitted and executed; no means the request will not be permitted and executed; ? means that the request is beyond the scope of the rule, that is, the request does not belong to the domain request.
The main differences between the PVME model and the BLP model on transition rules are the following:
In the PVME model when the Hypervisor managers the virtual machines, in this pair the subject can only be theHypervisor. Besides, the PVME model does notconsider the communications between VMs. As a result, the PVME model removes the rules corresponding to the rule 6 and 7 in BLP model.
The PVME model redefines the execution (e*) access property and adds a new rule (releasing execution (e*) access property).
The Hypervisor has the control (c*) access property when it manages VMs. Thus, we add two rules (acquiring and releasing control (c*) access property).
In the PVME model, the virtual machines have the same security level, no matter whether they are subjects or objects. Thus, we remove rule 10 of the BLP model and only keep the rule that changes objects’ security level.
The following is a detailed introduction of the composition of state transition rules in the PVME model, which is mainly divided into two cases:
If the subject is Hypervisor and the object is QEMU or the subject is QEMU and the object is Guest OS, we denote the subject as (if the subject is Hypervisor, i = 1; if the subject is QEMU (assuming that there are n VMs), ) and designate the object as , at this time the subject only has three accesses (read-only (r), write-only (a), write-read (w)) to the object , which is mapped to twostate transition rules.
If the subject is theHypervisor and the objects are VMs, we denote the subject as and denote the object as . As theHypervisor has absolute control over VMs, the subject can get access to subject in five ways (read-only (r), write-only (a), write-read (w), execute (e*) and control (c*)).In this case, on one hand the paper integrates the three access methods (the Hypervisor gets three types of access to the VMs, i.e., read-only (r), write-only (a), write-read (w)) into the first case, on the other the transition rules for the Hypervisor to get execute (e*) and control (c*) access to the VMs will be individually designed, which can totally map into four state transition rules. Rules 7–8 are used for subject Hypervisor to create and delete object VMs, and rule 9 can be used to change the security level of the object VMs.
Through the above analysis, in the PVME model, the corresponding set of requests is modified to
Table 1 that differs from the request set of BLP model. The following is a detailed explanation of the 9 rules of the PVME model.
Rule 1 (PVME- (get-read/append/write)). If the subject Hypervisor or QEMU. (if the subject is the Hypervisor, i = 1; if the subject is QEMU , ) needs to obtain the x (x is one of the read-only (r), write-only(a), write-read(w)) access to (the object is QEMU or Guest OS) or (the subject is theHypervisor) needs to get x access to (the object is Guest OS), the definition is . The rules is follows: If the decision is yes, adding x the way the subject getting access to the object to the current accessing set.
Rule 2 (PVME- (released-read/append/write)). If the subject Hypervisor or QEMU. (if the subject is the Hypervisor, i = 1; if the subject QEMU (assuming that there are n VMs), ) wants release the x (x is one of the read-only (r), write-only (a), write-read (w)) access to the (the object is QEMU or Guest OS) or the (the subject is theHypervisor) needs to release the x access to (the object is VM), the definition is , , the rule is as follows: If the decision is yes, removing x, where x is read-only (r), write-only (a), or write-read (w), from the set of accesses allowed for subject to access object .
Rule 3 (PVME- (get-execute)). The (the subject is theHypervisor, i=1) needs to obtain the execute (e*) access to (the objects are VMs, ), the definition is , and the rule is as follows: If the decision is yes, then adding execute (e*) into the set of accesses allowed for subject to access object .
Rule 4 (PVME- (release-execute)). The (the subject is the Hypervisor, i=1) needs to release the execute (e*) access to (the objects are VMs, ), the definition is , and the rule is as follows: If the decision is yes, then removing execute (e*) from the set of accesses allowed for subject to access object .
Rule 5 (PVME- (get-control)). (the subject is the Hypervisor, i=1) needs to obtain the control(c*) access to (the objects are VMs, ), the definition is , and the rule is as follows: If the decision is yes, then adding control (c*) to the set of accesses allowed for subject to access object .
Rule 6 (PVME- (release-control)). (the subject is the Hypervisor, i=1) needs to release the control (c*) access to (the objects are VMs, ), the definition is , and the rule is as follows: If the decision is yes, then removing the control (c*) the way the subject getting access to the object from the current accessing set.
Rule 7 (PVME- (create-vm-object)). (the subject is the Hypervisor, i=1) needs to create (the objects are VMs, ), the definition is , and the rule is as follows: In PVME-R7, the symbol represents that the right side is assigned to the left side (). The symbol means and the symbol expresses . The symbol in expression A\B suggests that A will be modified by B. Therefore the expression of rule denotes changing the security level of object in the security level vector to . The following rules will continue to use this expression.
If the decision is yes, the Guest VM will be created and the related elements will be added to security and object hierarchy.
Rule 8 (PVME- (delete-vm-object)). (the subject is the Hypervisor, i=1) needs to delete (the objects are VMs, ), the definition is , and the rule is as follows: The parameter n is the total number of the VMs and . Expression represents that the current access set b has all accesses to (Guest VMs). However, expression indicates that the deleted VMs in the current access set b can be visited as the objects by the subject with all the access ways.
If the decision is yes, the Guest VMs will be deleted and at the same time the related elements of current access set b or access matrix M or object hierarchy H will be removed as well.
Rule 9 (PVME- (change-vm-object-security-level)). Hypervisor needs to change the security level of object VM. The definition is , and the rule is as follows: PVME-*-property, in this case after the function’s conversion the state v still maintains the PVME-*-property. Specifically:
If the decision is yes, the security level of the object VM will be changed to .
For the whole system, if its original state is safe and its state transitions are onthe basis of the rules , then we can conclude that the system maintains PVME-*-property and PVME-ds-property and is a security system.