Chapter 2. Host Security
2.1. Why Host Security Matters
- 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
- 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
- The host physical machine should not use filesystem labels to identify file systems in the
initrdfile 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
initrdfile 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/sdb1or raw disks such as
/dev/sdb,you should configure LVM to only scan disks that are safe, using the
2.1.2. SELinux and Virtualization
Procedure 2.1. Creating and mounting a logical volume on a guest virtual machine with SELinux enabled
- 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
- Format the
NewVolumeNamelogical volume with a file system that supports extended attributes, such as ext3.
# mke2fs -j
- 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 (
/sys) or in home directories (
/root). This example uses a directory called
- Mount the logical volume.
- 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.localfile which makes the change persistent. The appended line may resemble this:
- Run the command to change the type of the mount point (
/virtstorage) and all files under it to
setfilescommands read the files in
# restorecon -R -v /virtstorage
touchcommand) on the file system.
# touch /virtstorage/newfile
# sudo ls -Z /virtstorage -rw-------. root root system_u:object_r:virt_image_t:s0 newfile
yum install policycoreutils-python) before running the command.
# semanage fcontext -a -t virt_image_t -f -b /dev/sda2 # restorecon /dev/sda2
The following table shows the SELinux Booleans which affect KVM when launched by libvirt.
|virt_use_comm||Allow virt to use serial/parallel communication ports.|
|virt_use_fusefs||Allow virt to read fuse files.|
|virt_use_nfs||Allow virt to manage NFS files.|
|virt_use_samba||Allow virt to manage CIFS files.|
|virt_use_sanlock||Allow sanlock to manage virt lib files.|
|virt_use_sysfs||Allow virt to manage device configuration (PCI).|
|virt_use_xserver||Allow virtual machine to interact with the xserver.|
|virt_use_usb||Allow virt to use USB devices.|
2.1.4. Virtualization Firewall Information
- 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.