Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Chapter 2. Host Security

2.1. Why Host Security Matters

When deploying virtualization technologies, you must ensure that the host physical machine and its operating system cannot be compromised. In this case the host is a Red Hat Enterprise Linux system that manages the system, devices, memory and networks as well as all guest virtual machines. If the host physical machine is insecure, all guest virtual machines in the system are vulnerable. There are several ways to enhance security on systems using virtualization. You or your organization should create a Deployment Plan. This plan needs to contain the following:
  • Operating specifications
  • Specifies which services are needed on your guest virtual machines
  • Specifies the host physical servers as well as what support is required for these services
Here are a few security issues to consider while developing a deployment plan:
  • Run only necessary services on host physical machines. The fewer processes and services running on the host physical machine, the higher the level of security and performance.
  • Enable SELinux on the hypervisor. Read Section 2.1.2, “SELinux and Virtualization” for more information on using SELinux and virtualization.
  • Use a firewall to restrict traffic to the host physical machine. You can setup a firewall with default-reject rules that will help secure the host physical machine from attacks. It is also important to limit network-facing services.
  • Do not allow normal users to access the host operating system. If the host operating system is privileged, granting access to unprivileged accounts may compromise the level of security.

2.1.1. Security Concerns when Adding Block Devices to a Guest

When using host block devices, partitions, and logical volumes (LVMs) it is important to follow these guidelines:
  • The host physical machine should not use filesystem labels to identify file systems in the fstab file, the initrd file or on the kernel command line. Doing so presents a security risk if guest virtual machines have write access to whole partitions or LVM volumes, because a guest virtual machine could potentially write a filesystem label belonging to the host physical machine, to its own block device storage. Upon reboot of the host physical machine, the host physical machine could then mistakenly use the guest virtual machine's disk as a system disk, which would compromise the host physical machine system.
    It is preferable to use the UUID of a device to identify it in the fstab file, the initrd file or on the kernel command line. While using UUIDs is still not completely secure on certain file systems, a similar compromise with UUID is significantly less feasible.
  • Guest virtual machines should not be given write access to whole disks or block devices (for example, /dev/sdb). Guest virtual machines with access to whole block devices may be able to modify volume labels, which can be used to compromise the host physical machine system. Use partitions (for example, /dev/sdb1) or LVM volumes to prevent this problem.
    If you are using raw access to partitions, for example /dev/sdb1 or raw disks such as /dev/sdb, you should configure LVM to only scan disks that are safe, using the global_filter setting.

Note

When the guest virtual machine only has access to image files, these issues are not relevant.

2.1.2. SELinux and Virtualization

Security Enhanced Linux was developed by the NSA with assistance from the Linux community to provide stronger security for Linux. SELinux limits an attacker's abilities and works to prevent many common security exploits such as buffer overflow attacks and privilege escalation. It is because of these benefits that all Red Hat Enterprise Linux systems should run with SELinux enabled and in enforcing mode.

Procedure 2.1. Creating and mounting a logical volume on a guest virtual machine with SELinux enabled

  1. Create a logical volume. This example creates a 5 gigabyte logical volume named NewVolumeName on the volume group named volumegroup. This example also assumes that there is enough disk space. You may have to create additional storage on a network device and give the guest access to it. This information is discussed in more detail in the Red Hat Enterprise Linux Virtualization Administration Guide. 
    # lvcreate -n NewVolumeName -L 5G volumegroup
  2. Format the NewVolumeName logical volume with a file system that supports extended attributes, such as ext3. 
    # mke2fs -j /dev/volumegroup/NewVolumeName
  3. Create a new directory for mounting the new logical volume. This directory can be anywhere on your file system. It is advised not to put it in important system directories (/etc, /var, /sys) or in home directories (/home or /root). This example uses a directory called /virtstorage 
    # mkdir /virtstorage
  4. Mount the logical volume. 
    # mount /dev/volumegroup/NewVolumeName /virtstorage
  5. Set the SELinux type for the folder you just created. 
    # semanage fcontext -a -t virt_image_t "/virtstorage(/.*)?"
    If the targeted policy is used (targeted is the default policy) the command appends a line to the /etc/selinux/targeted/contexts/files/file_contexts.local file which makes the change persistent. The appended line may resemble this: 
    /virtstorage(/.*)?    system_u:object_r:virt_image_t:s0
  6. Run the command to change the type of the mount point (/virtstorage) and all files under it to virt_image_t (the restorecon and setfiles commands read the files in /etc/selinux/targeted/contexts/files/). 
    # restorecon -R -v /virtstorage

Note

Create a new file (using the touch command) on the file system. 
# touch /virtstorage/newfile
Verify the file has been relabeled using the following command: 
# sudo ls -Z /virtstorage
-rw-------. root root system_u:object_r:virt_image_t:s0 newfile
The output shows that the new file has the correct attribute, virt_image_t.

2.1.3. SELinux

This section contains topics to consider when using SELinux with your virtualization deployment. When you deploy system changes or add devices, you must update your SELinux policy accordingly. To configure an LVM volume for a guest virtual machine, you must modify the SELinux context for the respective underlying block device and volume group. Make sure that you have installed the policycoreutils-python package (yum install policycoreutils-python) before running the command. 
# semanage fcontext -a -t virt_image_t -f -b /dev/sda2
# restorecon /dev/sda2
KVM and SELinux

The following table shows the SELinux Booleans which affect KVM when launched by libvirt.

KVM SELinux Booleans
SELinux BooleanDescription
virt_use_commAllow virt to use serial/parallel communication ports.
virt_use_fusefsAllow virt to read fuse files.
virt_use_nfsAllow virt to manage NFS files.
virt_use_sambaAllow virt to manage CIFS files.
virt_use_sanlockAllow sanlock to manage virt lib files.
virt_use_sysfsAllow virt to manage device configuration (PCI).
virt_use_xserverAllow virtual machine to interact with the xserver.
virt_use_usbAllow virt to use USB devices.

2.1.4. Virtualization Firewall Information

Various ports are used for communication between guest virtual machines and corresponding management utilities.

Note

Any network service on a guest virtual machine must have the applicable ports open on the guest virtual machine to allow external access. If a network service on a guest virtual machine is firewalled it will be inaccessible. Always verify the guest virtual machine's network configuration first.
  • ICMP requests must be accepted. ICMP packets are used for network testing. You cannot ping guest virtual machines if the ICMP packets are blocked.
  • Port 22 should be open for SSH access and the initial installation.
  • Ports 80 or 443 (depending on the security settings on the RHEV Manager) are used by the vdsm-reg service to communicate information about the host physical machine.
  • Ports 5634 to 6166 are used for guest virtual machine console access with the SPICE protocol.
  • Ports 49152 to 49216 are used for migrations with KVM. Migration may use any port in this range depending on the number of concurrent migrations occurring.
  • Enabling IP forwarding (net.ipv4.ip_forward = 1) is also required for shared bridges and the default bridge. Note that installing libvirt enables this variable so it will be enabled when the virtualization packages are installed unless it was manually disabled.

Note

Note that enabling IP forwarding is not required for physical bridge devices. When a guest virtual machine is connected through a physical bridge, traffic only operates at a level that does not require IP configuration such as IP forwarding.