2.2. Client Access Control
libvirt's client access control framework allows system administrators to setup fine-grained permission rules across client users, managed objects, and API operations. This allows client connections to be locked down to a minimal set of privileges.
In the default configuration, the
libvirtd daemon has three levels of access control:
- All connections start off in an unauthenticated state, where the only API operations allowed are those required to complete authentication.
- After successful authentication, a connection either has full, unrestricted access to all libvirt API calls, or is locked down to only "read only" operations, according to what socket the client connection originated on.
- The access control framework allows authenticated connections to have fine-grained permission rules to be defined by the administrator.
Every API call in libvirt has a set of permissions that will be validated against the object being used. Further permissions will also be checked if certain flags are set in the API call. In addition to checks on the object passed in to an API call, some methods will filter their results.
2.2.1. Access Control Drivers
The access control framework is designed as a pluggable system to enable future integration with arbitrary access control technologies. By default, the
none driver is used, which performs no access control checks at all. Currently, libvirt provides support for using polkit as a real access control driver. To learn how to use the polkit access driver see the configuration documentation.
The access driver is configured in the
/etc/libvirt/libvirtd.conf configuration file, using the access_drivers parameter. This parameter accepts an array of access control driver names. If more than one access driver is requested, then all must succeed in order for access to be granted. To enable 'polkit' as the driver, use the augtool command:
# augtool -s set '/files/etc/libvirt/libvirtd.conf/access_drivers[1]' polkit
To set the driver back to the default (no access control), enter the following command:
# augtool -s rm /files/etc/libvirt/libvirtd.conf/access_drivers
For the changes made to
libvirtd.conf to take effect, restart the libvirtd service.
# systemctl restart libvirtd.service2.2.2. Objects and Permissions
libvirt applies access control to all the main object types in its API. Each object type, in turn, has a set of permissions defined. To determine what permissions are checked for a specific API call, consult the API reference manual documentation for the API in question. For the complete list of objects and permissions, see libvirt.org.
2.2.3. Security Concerns when Adding Block Devices to a Guest
- The host physical machine should not use file system labels to identify file systems in the
fstabfile, theinitrdfile 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 file-system 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/etc/fstabfile, the/dev/initrdfile, or on the kernel command line. - Guest virtual machines should not be given write access to entire disks or block devices (for example,
/dev/sdb). Guest virtual machines with access to entire 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. See LVM Administration with CLI Commands or LVM Configuration Examples for information on LVM administration and configuration examples.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 theglobal_filtersetting. See the Logical Volume Manager Administration Guide for an example of an LVM configuration script using theglobal_filtercommand.
