Shulou(Shulou.com)06/02 Report--

How to parse the security extension KVMSEC of Linux kernel virtual machine, aiming at this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

1. Summary

The data center server farm based on virtualized PC is growing rapidly. The advantage of the architecture introduced in this article is to increase the global system security.

In this paper, we propose a structure called KvmSec, which is an extension of the Linux kernel virtual machine with the goal of increasing client security. KvmSec protects clients from viruses and kernel hacking tools. KvmSec has the following characteristics: transparent to the client, it is difficult to access the data from the compromised virtual machine, nor can it analyze the data of the other first client in the second client; it can provide secure communication between the client and the host; it can be deployed on both Linux host and Linux client. These features leverage the implementation of real-time monitoring and management systems. Furthermore, this design is superior to the security solutions designed by predecessors, and also conceives a roadmap for the next generation of security.

II. Introduction

Virtualization is an old concept, and this is its golden age. It is widely used in desktop PC, data centers and server clusters. By far, the most widely adopted x86 virtualization solutions are: VMware, Xen, User Mode Linux, Qemu, KVM. The reliability of virtualization solutions has also improved in recent years, but attacks on security services and operating systems on virtual machines are exasperating. Malicious intruders often successfully attack the system and gain administrator privileges. Like Trojans and backdoors can be inserted, important or private files can be accessed. Therefore, many types of attacks mean changing the file system. Intrusion protection tools usually check for file modifications, especially secure channels for those files.

The integrity tool and the data it collects are usually placed on the system it monitors. This is a problem, when a system is attacked by malicious programs, it can tamper with the monitoring system. KvmSec is added to the virtualization technology to cover the security of the entire system. Virtual clients are protected by additional boundaries. In particular, when a system monitor (including Virtual Machine Monitor) can provide a trusted computing base, thus making malicious programs unreachable on the monitoring system. In this way, even if the attacker successfully enters the virtual machine, the attack path cannot be deleted and the external security system cannot be shut down.

Contribution

This paper addresses the problem of client security monitoring when the server is hardened. Our main research contribution is the KvmSec system architecture, which can protect and monitor clients. The current progress is to allow the host to control unauthorized changes to the client in real time. When the client is abnormal, KvmSec can detect and react. It is an extension of the Linux Kernel Virtual Machine minimized access principle, and the monitoring system itself is visible.

Guidelines

The rest of this paper is organized as follows: section 3: investigate the existing technology and related work, and provide background information for our work. Section 4: describe the requirements and structure of KvmSec. Section 5: provide some implementation details. Section 6: discusses the comparison between KvmSec and previous results. Finally, section 7: draw a conclusion.

Background 3.1 Virtualization structure

Below we analyze the most relevant open source virtualization structures Xen and KVM to prove why we chose the latter. Full virtualization is a technology that uses CPU virtualization (technologies supported by AMD-V and Intel-VT). CPU supports this technical feature so that the operating system running in the virtual machine can run without modification without knowing the existence of a higher privilege level. Another virtualization technology is paravirtualization. It does not require the support of CPU virtualization technology, but usually requires a rewrite of the client operating system.

Xen, the most widely used virtualization solution, consists of Xen hypervisor (or VMM), privileged VM (Dom0), and normal VM (DomU) when the operating system is running. The characteristics of Xen are: 1) shared memory: communication channel between virtual machines; 2) Ethernet channel: signal channel between virtual machines; 3) shared memory access control: access control matrix, which describes the shared memory that can be accessed by virtual machines. The driver of Xen is defined in the Dom0 privilege domain. So the Dom0 handles the Imax O requests for other domains, and the responsibility of hypervisor is to convert from DomU to Dom0 when there is an Imax O operation request.

KVM, the new mainstream Linux virtualization solution, adds the kernel to the 2.6.20 kernel version. KVM (see the execution mode in figure 1) consists of a hypervisor (Linux kernel module), modified QEMU simulator software. KVM is a standard kernel module as a result of using standard, reliable, and frequently updated Linux device drivers. On the one hand, this is one reason why KVM is less vulnerable than Xen. Xen driver development is slower than standard Linux. On the other hand, the kernel code base is larger than Xen and potentially contains more weaknesses and problems. The comparison between Xen and KVM is not fully mature in "Table 1" .KVM, but it has better aspects than Xen, especially extensive hardware support and increased flexibility (redeploying a new version of KVM does not require a reboot). Moreover, more efforts have been made to add KVM and Qemu products.

3.2 related work

Below we briefly describe the problem of integrated monitor, which is used in the intrusion detection boundary area.

Integrated management structure that provides integrated metrics through SHA feeds. When loaded, executables, libraries, and kernel module summaries are calculated and stored in the modified Linux kernel itself. In addition, the hash of the integrated management structure is stored in a protected platform configuration register of a trusted computing platform module security chip attached to the hardware. in this way, the remote party can confirm the system integration by comparing the stored summary with the summary value of the remote computing. Although the performance impact of the summary is important and CPU-based virtualization support is not used, the integrated management structure provides a complete working reference structure.

The main leverage of Xen hypervisor does not have the following capabilities: Xen's sHype isolates virtual machines from mandatory access control, manages covert channels, and removes the operating system from the trusted base when the Xen is modified to protect users' private application data. XenFIT is a real-time file system integration tool that protects databases and FIT systems from attackers using Xen hypervisor quarantined parts. In fact, FIT and databases are deployed on separate virtual machines. Similarly, XenRIM consists of XenRIMU on DomU, which collects information from the client, and Xenrimd on Dom0 examines the information collected by XenRIMU and reports any system policy violations.

SecVisor uses CPU-based virtualization support to create a minimum hypervisor to ensure the integrity of the Linux kernel code and prevent code injection attacks. The SecVisor code base is very small, which reduces the size of the trusted computing base, but unfortunately only supports a single client. The results of SecVisor do not apply to scenarios where operating system security is hardened on the server. Moreover, he only succeeded in protecting kernel code, not kernel data.

Lares is an active virtualization-based structure that is placed on the Xen virtual machine and hook programs are installed on the client. To ensure that hook programs are not overwritten, Lares uses a memory protection system to allow write permissions per page to pass additional fingerprint checks. The first prototype of Lares seems to perform well, however, its monitoring uses hook programs and can be detected by performance analysis.

XenKimono is an intrusion detection system that aims to detect malicious intrusions by analyzing the internal data structures of the client kernel from the outside (Tamberi's subsequent work is related to this). All XenKimono modules are in the host, and the bare memory of the virtual machine is analyzed to see if there are any malicious programs (e.g. rootkits). The memory of the bare virtual machine is translated in the advanced kernel data structure, and kernel symbols are extracted from the DOMU kernel binary, and the Linux Kernel Crash Dump library is used. In this way, XenKimono can locate the DOMU kernel data structure in bare memory.

4. KVMSEC a security monitoring structure 4.1 threat model

We assume that the hypervisor and host kernel are part of the trusted computing base, however, the virtual machine is not. When the client is running, the attack is executed and malware is injected. When the client runs, it can become a slave to viruses, code injection, buffer overflows, or even all malicious attacks. Intruders may use defects to affect kernels and applications, and remotely use these defects in an attempt to gain root privileges.

4.2 requirements and warnings

Below, based on the threat model above, we describe the main requirements for virtual machine security systems, some warnings that can be addressed and possible ways to address them.

Requirements requirements: for virtual machines, a security system is associated with an intrusion detection system.

A security system must meet the following requirements:

RQ1 requires 1 Transparency transparency: this system should be minimally visible to virtual machines; that is, the monitoring system cannot be detected by potential intruders.

RQ2 requires that 2 Immunity to attacks from the Guset be immune to attacks from clients: hosts and clients should be protected from attacks from invaded clients; and the characteristics of hosts should not be affected.

RQ3 requires 3 Deployability deployability: the system should be deployable to mainstream hardware.

RQ4 requires 4 Dynamic reaction dynamic response: the system should detect attempts of invading clients and take appropriate responses to resist intrusions or zombie attacks.

Caveats warning:

PR1 A communication channel from the client to the host is required, and the host reads useful data and extracts information from the client, but it must be hidden in the client's user space (see RQ1).

PR2 A signal channel from the client to the host allows the host to be prompted when events occur on the client, but these should be hidden as much as possible (see RQ1).

Some PR3 access control on the channel is required to ensure consistency while protecting against information leakage; in this way, an access control mechanism will not have a negative impact on performance.

V. KVMSEC implementation

We implement the prototype of KvmSec to prove that our goal is feasible. The KvmSec architecture consists of many (optional) modules on the host and client kernels that communicate through a secure channel so that the host gets the correct client state. The main module of the monitoring system is located on the host, which makes it difficult for attackers on the client to access the host. Data: (a) can be collected by client processes or (b) can be collected and executed exclusively by processes on the host.

In particular, (a) allows the collection of more accurate and complete client data, but is easy to detect. A client daemon mainly collects data, which can help the host reduce the computing load. However, there is a compromise between the concealment of the monitoring system and reducing the host computing load. For (b) (no client components) this technology theoretically reduces detection (see RQ1), but allows only limited monitoring. For this reason, KvmSec prefers (a), and (b) is also supported.

It is worth noting that in KvmSec, each virtual machine uses its own private memory area to communicate with the host, which is completely independent of other virtual machines (see RQ2).

The KvmSec execution (see figure 2) is divided into two main parts: the host and the client. The two have a similar structure: 1) a kernel daemon manages and shares communication channels; 2) a module dynamically receives messages, analyzes them and responds (generates responses).

Below we mainly outline the solutions we have adopted for KvmSec, responding to the technical problems we face, while complying with previous requirements:

The SL1 host client communication system is not available in KVM and we have to use shared memory to make it communicate (see PR1).

SL2's lack of host and client signal channels in KVM led us to design a signaling mechanism that uses shared memory (see PR2). We also do not choose the event channel for Xen, because when the signal channel is implemented that way, the KvmSec can be seen by attackers who are already in the client.

SL3's lack of access control of shared memory in KVM makes us synchronize host and client in shared memory. To simplify access control management, each KvmSec virtual machine provides its own shared memory area for communicating with the host. Moreover, for each of the two one-way channels, a simple locking mechanism is implemented to synchronize access while the message is passing.

In KVM, unlike Xen, shared memory is not directly managed by hypervisor, but by the main emulation process Qemu-KVM. The communication channel that uses shared memory is consistent with RQ1. In fact, the result of using a virtual network socket between the host and the client is visible and in the voluntary communication channel (just as it happened in AIDE [1]). Moreover, the message handle is included in the client kernel module to make it as secure as possible, consistent with RQ2. On the host, the message handle is executed in the Qemu-KVM shared memory management module. KVM shared memory (see figure 3) consists of two data caches and two locks to protect the corresponding key areas.

To meet the RQ4 KvmSec should be able to actively monitor key processes running on the client. Currently, this functionality is not fully implemented; however, KvmSec can check the number of existing and active daemons on the client in stages. If one of these processes terminates (abnormally), the host will take appropriate statistics, including collecting data for authentication analysis, or even freezing the client or possibly restarting it (using clean disk images available). KvmSec can create a host-side database containing a summary of the calculations of the selected critical path files on the virtual machine. A runtime daemon can recalculate files whose hash is monitored. If a mismatch is found, the measures described above will be implemented.

The communication protocols in various modules (see figure 4) are similar. The significant differences between the host and the client are:

1. Managing and allocating shared memory: shared memory is allocated on the client and managed through kernel modules, while on the host, shared memory must already be allocated (in the virtual machine) and its management is assigned to the Qemu-KVM process.

two。 Number of modules: in the virtual machine, we only need a pair of modules, because shared memory management is assigned to the kernel, and in the host, we need three modules, which will be extended in the next section.

5.1 KvmSec Host

The host part consists of three modules: KvmSecD,DM,Qemu-KVM.

(1) KvmSecD: it is a daemon and accesses all virtual machine address spaces. In addition, this module knows the daemons of the other two hosts (Qemu-KVM and DM) because those two daemons register their pid to KvmSecD.

The communication channel between DM:KvmSecD and DM is managed by a combined character device (called char_dev) and controlled by DM through the IOCTL interface and POSIX signal. The capabilities of character devices are extended using the IOCTL interface, defining access policies to these devices by allowing a series of macros to interact with kernel modules.

At each communication phase, the kernel element (that is, buffers) is protected by the kernel module locking. (our code uses the following primitive elements for this purpose: semaphores (sem wait), mutexes (mux), atomic variables (reg and qemu alive).) Access to buffer is done through a process (DM) using macros because critical areas are already protected. In this way, the system can be upgraded with more than one user-space process because they access buffer through these macros.

(2) DM:DM is the first of two user space daemons and consists of two threads:

1.DM-it is the main thread that manages: a) communication between DM and KvmSecD,DM and Qemu; b) creating and receiving messages from shared memory across Qemu-KVM; and c) registering DM's pid into KvmSecD.

2.WATCHER-this is the second thread that manages: a) startup of Qemu-KVM; b) registration of Qemu-KVM 's pid into KvmSecD; c) abnormal termination of Qemu-KVM

Communication channel with Qemu: since the DM and Qemu processes are executed in user space, we can use any Linux System V IPC tool for interprocess communication. Specifically, we use PIPE (or FIFO)

(3) Qemu-KVM: Qemu-KVM is a modified Qemu that combines the communication mechanism with the kernel module KVM.

Communication protocol between Qemu and VM (host and VM): the communication protocol between virtual machine and host relies on synchronous access to the shared memory area. Qemu uses the cpu_physical_memory_rw function to allow writing to the memory of the virtual machine. Host-VM synchronization is based on this function. In this way, multi-access read-write buffers are synchronous, protected, and operating system independent.

5.2 KvmSec client

The KvmSec client consists of two modules: KvmSecDVM and DMVM

(1) KvmSecDVM: it is the Linux kernel daemon that manages the communication between virtual machines and hosts. This daemon has access to kernel memory. This module allocates shared memory for communication. Also, we assign a physical address where the buffer holds the shared memory. Communication protocol is the same as above.

(2) DMVM: it is a daemon that handles the task of monitoring, analyzing, and creating responses. This module manages messages for shared memory. As with the host, a character device (char_dev) is used as its communication channel with the KvmSecDVM. Communication protocols are also similar to DM and KvmSecD. This module checks critical path file access and corrects it. Future execution of this module will provide space for other integration check plug-ins.

VI. Discussion

The goal of KvmSec is to provide potentially undetected, uncompromised systems that can capture violations of virtual machine integrity. Compared with previous systems, the features provided by KvmSec are as follows:

Performance: we have performed basic performance tests to compare KvmSec with Kvm. In particular, we measure the time requirement: execute the standard 2.6 kernel using standard configuration (Kernel build) and compress its source code to tarball (Kernel unbz2). The test uses Vaio laptops, 2GB memory, single-core 2.1Ghz processors, and runs Fedora 9 x86 (host and virtual machines). The preliminary results are shown in Table 2, which shows that KvmSec requires only a little more than Kvm.

Transparent: KvmSec's client and host messages are not controlled by the standard network stack (which occurs in the mainstream integrity structure, see Section 3.2); all of them are undetectable (RQ1); KvmSec relies only on its own internal communication protocol (see Section 5.1), making it independent of the adopted virtual machine system, unlike Xen's hypervisor. Moreover, each virtual machine in KvmSec has its own shared memory area for host and virtual machine communication; this allows each communication channel to be managed independently and independent of other channels (RQ2).

Signals: KvmSec is potentially less detected than other systems (such as XenRim) because there is no obvious signal channel (RQ1) between the host and the virtual machine (see section 4).

Daemon processing: KvmSec can share monitoring tasks between the host and the client. This will provide a performance advantage and increase the quality of monitoring under normal circumstances. Fair trading allows the monitoring client module to make the entire system more likely to be detected. The client module is not strictly required in the KvmSec structure.

Resist compromise: note that the kernel detection system is on the host, which makes the system difficult to break into. Also, the module that manages host and client communication is in the client kernel (see section 4) (RQ2).

Deployment: KvmSec can be deployed in any of the latest Linux kernels, while other recommendations (such as XenKimono) require Xen virtualization systems to be installed and run on host hosts. Next, KvmSec supports more host platforms than Xen-based solutions (see Section 3.1) (RQ3).

VII. Conclusion

We propose a structure that extends the Linux kernel virtual machine: kvmsec. In particular, we extend KVM to focus on security, providing a solution (KvmSec) for real-time integrity monitoring of virtual machines. As far as we know, this is the first security topic for Linux KVM. The KvmSec prototype we developed has the following characteristics: transparent to clients (even clients that have been maliciously hacked); support for full virtualization, which will make the client side less detected; it can collect data and interact with clients, and its kernel is stored on a protected host; it provides two secure ways of hypervisor-to-client communication; it can be deployed on x86 and x86 clients 64 machines.

This is the answer to the question about how to parse the security extension KVMSEC of the Linux kernel virtual machine. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.