At the recent Red Hat Summit 2016, Scott Herold, a product manager for RHV Technologies and Prasad Pandit, a software engineer for Red Hat discussed ways to assess and mitigate potential security flaws in the Red Hat virtualization spectrum.
The growth of virtualization has been paralleled by the growth of more complex environments with greater susceptibility to security risks, especially when resources such as hardware components, networks and storage are shared by multiple tenants or clients.
Here’s a rundown of the types of threats to virtualization environments, and ways they can be mitigated:
Types of threats
Denial of Service (DOS) attacks
A Denial of Service attack generally involves undesired consumption of resources intended to adversely impact a guest or host, preventing it from running effectively or crippling it altogether. For example, directing excessive network traffic at a target system so that it cannot respond to legitimate traffic. DOS attacks can affect both virtual and non-virtual hosts, but are especially damaging in a multi-tenanted virtual environment since more than one system can be impacted. Examples include divide by zero errors at the QEMU layer, infinite loops, null de-references or invalid memory access.
Memory corruption and leakage
Memory corruption and leakage can occur in guests, hosts, and hypervisors (as well as on other physical systems). “We’re still finding buffer overflows in operating systems, at the hypervisor layer,” Herold commented. He pointed out that live virtual machine migrations involve sending unencrypted data over a private network, and therefore plain text memory contents are transmitted over the wire. If exploited, this can lead to buffer overflows, out of bounds reads (information disclosure) or escalated privilege access to run as a higher level user and gain access to the entire environment.
A guest-to-host escape involves executing code outside the constraints of a guest VM directly on the host hypervisor where it is running. Some examples include the vulnerabilities known as Venom and Dark Portal. Venom involved out of bounds memory access while running floppy drive controller commands and Dark Portal was a buffer overflow while conducting VGA read-write operations.
You can use control groups to protect the four core resources (memory, CPU, disk or network) that can be exploited. These groups will use resource limiting and control to make sure one VM can’t use too much of a given resource. A kernel feature controls allocation and isolation of resources, as well as accounting/measurement and prioritization. Control groups can also be set up for services or user processes.
The tools that are used to create control groups are the cgcreate (create control groups) and cgexec (start a process in a control group) commands. Red Hat also offers an open source application programming interface (API) called libvert, which is a daemon/ management tool for platform virtualization.
SELinux is Red Hat’s Linux Security Module and it operates by implementing Mandatory Access Controls (MAC). Available in Red Hat Enterprise Linux 5 and up, SELinux labels all processes (subjects) and files (objects) and utilizes policy rules to protect them. SELinux has two modes, enforcing and permissive, and provides Multi Level Security (MLS) to ensure one virtual guest can’t access files owned by another guest.
SELinux operates by restricting access using levels based on role and type. It utilizes auditd to log messages to /var/log/audit/audit.log.
sVirt (secure virtualization) combines SELinux and virtualization. It’s integrated into libvirt (versions 0.6.1 and later) and available in Red Hat Enterprise Linux 6 and up. Since each guest runs as an individual process on the host, sVirt isolates these processes via Mandatory Access Controls to enforce Multi Level Security.
“sVirt helped protect Red Hat with Dark Portal and Venom,” Herold stated. “Even if users could get outside the VMs, the context was locked down and all external access denied.”
SecComp is a kernel feature still early in development which also provides sandboxing like capabilities. It limits system calls by processes to reduce the kernel attack surface and the damage that can be caused. Essentially a system call filtering scheme, it uses the Berkeley Packet Filter (BPF) interface via a dual process-approach.
Here are some practical takeaways from the session:
- The Guest VM is a process which could be compromised through one of the threats outlined above
- Ensure guests VMs have the least possible privileges on the host, and run with non-privileged accounts where possible
- Contain VMs within a sandbox environment of their own using control groups
- Disable devices/services not in use on guests and hosts. It’s also a good idea to review the virtual environment periodically to decommission any unused guests.
- SELinux and sVirt are a boon, so don’t disable these. Instead, learn how they work and apply them where they will be beneficial
- Keep host and guest software up to date by applying operating system and application patches. This is especially critical on the hypervisors since these are hosting multiple systems.
In addition, I recommend setting up security and resource alerts to notify responsible staff when malicious activity occurs and system performance/health is endangered.
Red Hat Insights predictive analytics tool gets updates for managing risks, containers and private cloud
Red Hat Enterprise Linux ‘getting in the way’ and needs to evolve, says product director
Red Hat goes all in on OpenShift and containers at Red Hat Summit 2016
Red Hat’s open source success story built on killing complexity in IT