[libvirt] RFC: extending sVirt to confine host apps which talk to libvirtd
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism. Securing KVM virtualization hosts with MAC ========================================== This document looks at the task of securing KVM virtualizaton hosts using mandatory access control technologies, with focus on SELinux. At the time of writing there have been two phases of development, and this document makes proposals for a third phase. Phase 1: circa 2006 ------------------- Goal: Protect the host from a compromised virtual machine. The first phase of development had the modest goal of protecting the host from attack by a compromised virtual machine. To achieve this, the KVM processes are configured such that they will run under a confined security context ('virt_t' in the SELinux reference policy), which blocks access to any host resources not labelled ('virt_image_t') for use by virtual machines. The primary limitations of this initial implementation is that while the virtual host is secured, there is no protection between virtual machines. This can be considered a regression in isolation as compared to that offered by non-virtualized hosts. The second limitation is that the virtualization admin has to take care to ensure the host resources intended for use by the virtual machines are correctly labelled. This is a manual setup taks unless the images are kept in a preset location (/var/lib/libvirt/images in the SELinux reference policy). Phase 2: March 2009 ------------------- Goal: Protect virtual machines from each other The second phase of development has the goal of providing isolation between virtual machines that is comparable to that achieved between physical machines. This piece of work is commonly referred to as "svirt". The achieve this, the KVM processes are each configured to run under a dedicated security context, which blocks access to any resources not explicitly assigned to that virtual machine. In the SELinux implementation, the base context "svirt_t" has a unique MCS category ("c240,c955") appended to form a unique security context "system_u:system_r:svirt_t:s0:c240,c955". For each host resource to be assigned to the virtual machine, the base context "svirt_image_t" is combined with the same MCS category to form a unique resource security context "system_u:object_r:svirt_image_t:s0:c240,c955". The assignment of virtual machine security contexts and labelling of resources can be done statically by the administrator / management application, or dynamically by the libvirtd daemon. The latter removes much of the administrator burden. The second phase has addressed the major guest security limitation of the first phase, and eased the burden placed on host administors. Attention can now focus on the security of the host management software stack. Client applications communicate with the libvirtd daemon using a simple sockets based RPC protocol. Thus operations initiated by client applications which run under one security context are in fact invoked under the libvirtd daemon's security context. Since the libvirtd daemon is a highly privileged, almost unconfined process, this provides a means for applications to elevate their privileges. A second problem with the current model is seen when looking at guest migration between hosts. During migration, there are two QEMU processes running for the same virtual machine, one process on each host. The dynamic assignment of MCS values to form unique security contexts is done on a per host basis, so there is no guarantee that the VM on host A will be using (or be able to use) the same security context on the target host of migration. This is not neccessarily a problem if the guest is using block devices, since block device inode labels are only visible to a single host. With a shared filesystem that supports SELinux labelling, like GFS2, both QEMU processes must run in the same security context to allow them both to access the associated files. Phase 3: June 2011 ------------------ Goal: Protect virtual machines from host applications The third phase of development has the primary goal of honouring the confinement of client applications talking to libvirtd, when performing operations on virtual machines and other managed objects (storage pools, host devices, virtual networks, secrets, etc). Every application connecting to libvirt has an associated security context. Every object managed by libvirtd will have an associated security context. When an operation is invoked via a libvirt API the client application security context will be checked against the target object context, before proceeding. Thus applications will not be able to make use of a libvirtd connection to perform operations that are otherwise blocked. The secondary goal is to add further flexibility and safety to the way MCS categories are assigned, and files are relabelled. Instead of maintaining a local database of assigned labels, there must be some shared storage where label usage can be recorded. At its simplest this can be an NFS share, with one file per MCS category and locking with fcntl(). An alternative would to be acquire leases using a lock manager such as sanlock. In addition, the guest configuration will be enhanced such that a guest can be assigned a statically chosen security context, but still make use of dynamic relabelling of resources. Finally the existing boolean mode of 'static' vs 'dynmamic' label generation will be turned into a tri-state, introducing a 'hybrid' mode where the client supplies a custom base context, and the MCS part is still auto-generated. Usage scenarios --------------- To aid in development a couple of relevant core use cases or usage scenarios have been identified: 1. A virtual machine monitoring application For this example, consider the simple monitoring application 'virt-top'. This application displays a list of all virtual machines on the host and their associated resource utilization (CPU, disk, network). This application has no need to be able to stop/start/define virtual machines, nor do any operation related to host devices, storage, or networking. Traditionally this application is written to use a read only libvirt connection. With enhanced access control from libvirtd, the policy would define a new security context 'virt_top_t' for the 'virt-top' application. This policy would allow 'list', 'read', 'readstats' on the 'domain' object type. 2. A multi-guest, multi-user MLS enabled host For this example, consider a virtualizaton host with MLS policy that is running multiple virtual machines, for a variety of different users. A user with the security level "restricted" must not be allowed to control virtual machines with a security level of "confidential". Conversely a user with security level "secret" must not be allowed to create virtual machines with a security level of "unclassified". With enhanced access control from libvirtd, getpeercon() would provide the security context of the client application (user). The client context would be used to perform an AVC when any API operation is invoked, thus ensuring that the client's MLS label is honoured in access control checks. The effect would be that when an 'restricted' user asked for a list of virtual machines only virtual machines at level 'restricted' or below would be returned. Or when a "secret" user asked to start a guest when a security level of 'unclassified', the operation would be denied. 3. Identity transitions from trusted agents For this example, consider a trusted agent such as libvirt-qpid, or libvirt-snmp, which translates the libvirt API from its native model, into an alternate access model. In such an example, the agent talking to libvirtd will have authenticated itself. The peer identity that libvirtd sees, however, is that of the agent, not the ultimate (end-user) client. In such a case it will desirable to allow a trusted agent to transition to a different identity when performing operations. An end user running under context "unconfined_u:unconfined_r:virt_top_t:s0-s0:c0.c1023" may talk to the libvirt-qpid agent which runs under the context "system_u:system_r:virt_qpid_t:s0-s0:c0.c1023". The libvirt-qpid connects to libvirtd which sees 'virt_qpid_t' as the client type. The policy is written to allow transitions from 'virt_qpid_t' to the 'virt_top_t' type, so when the virt-top client connects to libvirt-qpid, it changes its identity to 'virt_top_t'. From that point onwards, all AVC checks honour the privileges of the ultimate end user application, rather than the libvirt-qpid intermediary. The same mechanism also ensures that the client application MLS level is transferred via the libvirt-qpid agent to libvirtd. Anticipated Development tasks ----------------------------- 1. Extend the domain XML to add a third attribute to the <seclabel> element relabel="yes|no", to control whether libvirtd will automatically label resources assigned to a guest. If the existing 'mode' attribute is "dynamic", then relabelling will default to enabled, while if it is 'static', then relabelling will default to disabled. Also change 'mode' to allow a new 'hybrid' value. 2. Determine how to maintain/identify security labels for other managed objects, including virStoragePoolPtr, virStorageVolPtr, virSecretPtr, virNetworkPtr, virInterfacePtr, virNodeDevicePtr, an host level APIs without any explicit managed object. 3. Extend XML for non-domain objects to implant security labels as identified in step 2. 4. Create an internal virIdentity struct to store the identity of the client. This will include at least the x509 distinguished name, the SASL username, the SELinux context (getpeercon()) and UNIX username/group (SCM_CREDENTIALS). 5. Create a new public API to allow a client application to supply a new identity, allowing them to pass a new x509 distinguished name, SASL username, SELinux context and UNIX username/group. 6. Extend the libvirtd daemon such that the current identity is stored in a thread local whenever invoking a public API operation. 7. Extend the QEMU driver such that a suitable identity is set when performing autonomous background operations such as domain auto-start and core dump, in a non-API thread. 8. Create a set of internal access control helper APIs in $libvirt/src/accesscontrol/. There will be one API for each managed object, talking an object pointer, and an operation identifier (from an enum). 9. Create a simple impl of the access control APIs which defines roles for groups of user identities, and grants privileges to each role based on the operation names. This allows for simple testing of internal infrastructure, and an RBAC mechanism for users who lack SELinux in their OS. 10. Implant access control checks into the main codepaths of every driver method implementations in the QEMU driver. 11. Change the SELinux reference policy to define the new security types and access vectors for the libvirt objects & associated API calls. 12. Create a SELinux impl of the access control APIs which invokes avc_has_perm() using the client's SELinux context. This is intended to be the primary RBAC mechanism for Fedora/RHEL virtualization hosts. 13. Write policy to confine targetted applications like virt-top, virt-mem. 14. Extend libvirt-snmp, libvirt-cim, libvirt-qpid to pass through the client identity to libvirtd. Technical Notes / Issues ------------------------ 1. Adding new SELinux security classes / access vectors The selinux security classes are defined in /usr/include/selinux/flask.h and access vectors in /usr/include/selinux/av_permissions.h Both of these files are automatically by a script in the selinux reference policy code '$serefpolicy/policy/flask/flask.py'. The master data files are in the same directory, 'access_vectors' and 'security_classes'. Once generated, the headers need to be manually copied into the libselinux package sources. APIs are added to libvirt on a very frequent basis. What is the process for applying access control to them if the SELinux policy does not yet have a suitable access vector / security class defined ? Do we need a generic 'admin' access vector we can use as catch all, until more specific vectors can be defined for the new APIs. Desirable to avoid having to lock-step upgrade libvirt with selinux policy for all additions to the libvirt public API. 2. Security contexts for libvirt managed objects virDomainPtr: Already embedded in XML, unless using dynamic labelling in which case context is assigned at startup. virNetworkPtr: No existing security context, nor any object on disk that could be used. Follow example of domains and embed <seclabel> in the XML. Assign unique MCS category per network and ensure that daemons launched per network (dnsmasq, radvd) inherit the MCS category. virSecretPtr: No existing security context. Secrets may be associated with disk paths for VMs. Could copy the security context of the guests and apply it to the secret, or have a dedicated type svirt_secret_t and just copy the MCS category. Hard to make it work for guests with dynamic MCS assignment. virStoragePoolPtr: No existing security context. Some pool types have objects existing on the host filesystem eg SCSI HBAs have a directory in sysfs, filesystem dirs have a directory somewhere, LVM has directory for the volume group in /dev. Other pool types have no object on disk anywhere convenient. eg Sheepdog. Other pool types only have an object on disk when the pool is active (eg iSCSI, NFS). So there is nothing to use for API checks when the pool is inactive. Likely have to ignore whatever associated resource is on disk and just store a security context in the XML config as with virDomainPtr/virNetworkPtr. virStorageVolPtr: Currently reports the SELinux security label associated with the file on disk. Not all pool types neccessarily have volumes with a corresponding file on disks (eg Sheepdog). virNodeDevicePtr: No existing security context. Most data comes from udev or HAL databases, though ultimately much is available in sysfs. When detaching PCI devices from host drivers, files in sysfs are used. When creating/deleting NPIV adapters sysfs is used. Thus could use sysfs file labels for AVC checks ? virConnectPtr: All host level APIs for which there is no other object aside from the nebulous concept of the 'host'. APIs are all readonly, eg query host capabilities, query free memory, CPU stats, etc. What if we gain APIs to make write calls. virInterfacePtr: No existing security context. Currently using netcf to get data from /etc/sysconfig/network-scripts/ifcfg-XXX files, but can't assume those file names since that is Fedora/RHEL specific. Might not even use netcf if it talks directly to network manager. Does netcf need to expose a security label based on the ifcfg-XXX file ? 3. Security labelling config modes When creating a guest the following XML snippets can be used. a. Default type, dynamic MCS, automatic relabelling <seclabel type='selinux' mode='dynamic' relabel='yes'/> b. Custom type, dynamic MCS, automatic relabelling <seclabel type='selinux' mode='hybrid' relabel='yes'> <label>system_u:system_r:mysvirt_t</label> <imagelabel>system_u:object_r:mysvirt_image_t</imagelabel> </seclabel> c. Default type, dynamic MCS, no relabelling <seclabel type='selinux' mode='dynamic' relabel='no'/> Does this mode make any sense, since admin doesn't know MCS category upfront ? Possibly only useful if the guest only has readonly disks. d. Custom type, dynamic MCS, no relabelling <seclabel type='selinux' mode='hybrid' relabel='no'> <label>system_u:system_r:mysvirt_t</label> </seclabel> Same question about whether it makes sense e. Custom type, static MCS, auto relabelling <seclabel type='selinux' mode='static' relabel='yes'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> <imagelabel>system_u:system_r:mysvirt_image_t:s0:c123,c456</imagelabel> </seclabel> f. Custom type, static MCS, no relabelling <seclabel type='selinux' mode='static' relabel='no'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> </seclabel> 4. Time at which to apply checks / source context It would be desirable to restrict the ability to use automatic file relabelling within the policy. If a client application defines a guest with the 'relabel=yes' attribute set, at what time should this usage be validated ? Validate at the time the guest is defined ? This ensures the app defining the guest is suitably privileged, but the file labels might be changed by the time the guest starts. Validate at the time the guest is started ? This minimises the window between access check being performed, and libvirtd actually performing the relabel operation. The app starting the guest might be different from the one defining the guest though ? Check at both define + start time ? What source security context should we use when performing autostart of virtual machines ? Normally when starting a VM, the check would be performed using the context of the client invoking the start API, but there is no such client when autostart occurs. Should we instead perform a 'start' operation check whenever the 'autostart' flag is turned on by a client ? Or check the autostart operation against some generic source context ? -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/06/2011 10:41 AM, Daniel P. Berrange wrote:
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism.
Securing KVM virtualization hosts with MAC ==========================================
This document looks at the task of securing KVM virtualizaton hosts using mandatory access control technologies, with focus on SELinux. At the time of writing there have been two phases of development, and this document makes proposals for a third phase.
Phase 1: circa 2006 -------------------
Goal: Protect the host from a compromised virtual machine.
The first phase of development had the modest goal of protecting the host from attack by a compromised virtual machine. To achieve this, the KVM processes are configured such that they will run under a confined security context ('virt_t' in the SELinux reference policy), which blocks access to any host resources not labelled ('virt_image_t') for use by virtual machines.
The primary limitations of this initial implementation is that while the virtual host is secured, there is no protection between virtual machines. This can be considered a regression in isolation as compared to that offered by non-virtualized hosts. The second limitation is that the virtualization admin has to take care to ensure the host resources intended for use by the virtual machines are correctly labelled. This is a manual setup taks unless the images are kept in a preset location (/var/lib/libvirt/images in the SELinux reference policy).
Phase 2: March 2009 -------------------
Goal: Protect virtual machines from each other
The second phase of development has the goal of providing isolation between virtual machines that is comparable to that achieved between physical machines. This piece of work is commonly referred to as "svirt". The achieve this, the KVM processes are each configured to run under a dedicated security context, which blocks access to any resources not explicitly assigned to that virtual machine. In the SELinux implementation, the base context "svirt_t" has a unique MCS category ("c240,c955") appended to form a unique security context "system_u:system_r:svirt_t:s0:c240,c955". For each host resource to be assigned to the virtual machine, the base context "svirt_image_t" is combined with the same MCS category to form a unique resource security context "system_u:object_r:svirt_image_t:s0:c240,c955".
The assignment of virtual machine security contexts and labelling of resources can be done statically by the administrator / management application, or dynamically by the libvirtd daemon. The latter removes much of the administrator burden.
The second phase has addressed the major guest security limitation of the first phase, and eased the burden placed on host administors. Attention can now focus on the security of the host management software stack. Client applications communicate with the libvirtd daemon using a simple sockets based RPC protocol. Thus operations initiated by client applications which run under one security context are in fact invoked under the libvirtd daemon's security context. Since the libvirtd daemon is a highly privileged, almost unconfined process, this provides a means for applications to elevate their privileges.
A second problem with the current model is seen when looking at guest migration between hosts. During migration, there are two QEMU processes running for the same virtual machine, one process on each host. The dynamic assignment of MCS values to form unique security contexts is done on a per host basis, so there is no guarantee that the VM on host A will be using (or be able to use) the same security context on the target host of migration. This is not neccessarily a problem if the guest is using block devices, since block device inode labels are only visible to a single host. With a shared filesystem that supports SELinux labelling, like GFS2, both QEMU processes must run in the same security context to allow them both to access the associated files.
Phase 3: June 2011 ------------------
Goal: Protect virtual machines from host applications
The third phase of development has the primary goal of honouring the confinement of client applications talking to libvirtd, when performing operations on virtual machines and other managed objects (storage pools, host devices, virtual networks, secrets, etc). Every application connecting to libvirt has an associated security context. Every object managed by libvirtd will have an associated security context. When an operation is invoked via a libvirt API the client application security context will be checked against the target object context, before proceeding. Thus applications will not be able to make use of a libvirtd connection to perform operations that are otherwise blocked.
The secondary goal is to add further flexibility and safety to the way MCS categories are assigned, and files are relabelled. Instead of maintaining a local database of assigned labels, there must be some shared storage where label usage can be recorded. At its simplest this can be an NFS share, with one file per MCS category and locking with fcntl(). An alternative would to be acquire leases using a lock manager such as sanlock. In addition, the guest configuration will be enhanced such that a guest can be assigned a statically chosen security context, but still make use of dynamic relabelling of resources. Finally the existing boolean mode of 'static' vs 'dynmamic' label generation will be turned into a tri-state, introducing a 'hybrid' mode where the client supplies a custom base context, and the MCS part is still auto-generated.
Usage scenarios ---------------
To aid in development a couple of relevant core use cases or usage scenarios have been identified:
1. A virtual machine monitoring application
For this example, consider the simple monitoring application 'virt-top'. This application displays a list of all virtual machines on the host and their associated resource utilization (CPU, disk, network). This application has no need to be able to stop/start/define virtual machines, nor do any operation related to host devices, storage, or networking. Traditionally this application is written to use a read only libvirt connection.
With enhanced access control from libvirtd, the policy would define a new security context 'virt_top_t' for the 'virt-top' application. This policy would allow 'list', 'read', 'readstats' on the 'domain' object type.
2. A multi-guest, multi-user MLS enabled host
For this example, consider a virtualizaton host with MLS policy that is running multiple virtual machines, for a variety of different users. A user with the security level "restricted" must not be allowed to control virtual machines with a security level of "confidential". Conversely a user with security level "secret" must not be allowed to create virtual machines with a security level of "unclassified".
With enhanced access control from libvirtd, getpeercon() would provide the security context of the client application (user). The client context would be used to perform an AVC when any API operation is invoked, thus ensuring that the client's MLS label is honoured in access control checks. The effect would be that when an 'restricted' user asked for a list of virtual machines only virtual machines at level 'restricted' or below would be returned. Or when a "secret" user asked to start a guest when a security level of 'unclassified', the operation would be denied.
3. Identity transitions from trusted agents
For this example, consider a trusted agent such as libvirt-qpid, or libvirt-snmp, which translates the libvirt API from its native model, into an alternate access model. In such an example, the agent talking to libvirtd will have authenticated itself. The peer identity that libvirtd sees, however, is that of the agent, not the ultimate (end-user) client. In such a case it will desirable to allow a trusted agent to transition to a different identity when performing operations.
An end user running under context "unconfined_u:unconfined_r:virt_top_t:s0-s0:c0.c1023" may talk to the libvirt-qpid agent which runs under the context "system_u:system_r:virt_qpid_t:s0-s0:c0.c1023". The libvirt-qpid connects to libvirtd which sees 'virt_qpid_t' as the client type. The policy is written to allow transitions from 'virt_qpid_t' to the 'virt_top_t' type, so when the virt-top client connects to libvirt-qpid, it changes its identity to 'virt_top_t'. From that point onwards, all AVC checks honour the privileges of the ultimate end user application, rather than the libvirt-qpid intermediary. The same mechanism also ensures that the client application MLS level is transferred via the libvirt-qpid agent to libvirtd.
Anticipated Development tasks -----------------------------
1. Extend the domain XML to add a third attribute to the <seclabel> element relabel="yes|no", to control whether libvirtd will automatically label resources assigned to a guest. If the existing 'mode' attribute is "dynamic", then relabelling will default to enabled, while if it is 'static', then relabelling will default to disabled. Also change 'mode' to allow a new 'hybrid' value.
2. Determine how to maintain/identify security labels for other managed objects, including virStoragePoolPtr, virStorageVolPtr, virSecretPtr, virNetworkPtr, virInterfacePtr, virNodeDevicePtr, an host level APIs without any explicit managed object.
3. Extend XML for non-domain objects to implant security labels as identified in step 2.
4. Create an internal virIdentity struct to store the identity of the client. This will include at least the x509 distinguished name, the SASL username, the SELinux context (getpeercon()) and UNIX username/group (SCM_CREDENTIALS).
5. Create a new public API to allow a client application to supply a new identity, allowing them to pass a new x509 distinguished name, SASL username, SELinux context and UNIX username/group.
6. Extend the libvirtd daemon such that the current identity is stored in a thread local whenever invoking a public API operation.
7. Extend the QEMU driver such that a suitable identity is set when performing autonomous background operations such as domain auto-start and core dump, in a non-API thread.
8. Create a set of internal access control helper APIs in $libvirt/src/accesscontrol/. There will be one API for each managed object, talking an object pointer, and an operation identifier (from an enum).
9. Create a simple impl of the access control APIs which defines roles for groups of user identities, and grants privileges to each role based on the operation names. This allows for simple testing of internal infrastructure, and an RBAC mechanism for users who lack SELinux in their OS.
10. Implant access control checks into the main codepaths of every driver method implementations in the QEMU driver.
11. Change the SELinux reference policy to define the new security types and access vectors for the libvirt objects & associated API calls.
12. Create a SELinux impl of the access control APIs which invokes avc_has_perm() using the client's SELinux context. This is intended to be the primary RBAC mechanism for Fedora/RHEL virtualization hosts.
13. Write policy to confine targetted applications like virt-top, virt-mem.
14. Extend libvirt-snmp, libvirt-cim, libvirt-qpid to pass through the client identity to libvirtd.
Technical Notes / Issues ------------------------
1. Adding new SELinux security classes / access vectors
The selinux security classes are defined in /usr/include/selinux/flask.h and access vectors in /usr/include/selinux/av_permissions.h Both of these files are automatically by a script in the selinux reference policy code '$serefpolicy/policy/flask/flask.py'. The master data files are in the same directory, 'access_vectors' and 'security_classes'. Once generated, the headers need to be manually copied into the libselinux package sources.
You do not need to do this anymore. libselinux does not care about the access vectors, they are named in your application.Well
APIs are added to libvirt on a very frequent basis. What is the process for applying access control to them if the SELinux policy does not yet have a suitable access vector / security class defined ? Do we need a generic 'admin' access vector we can use as catch all, until more specific vectors can be defined for the new APIs. Desirable to avoid having to lock-step upgrade libvirt with selinux policy for all additions to the libvirt public API.
Well one benefit would be unconfined_t, although I am not sure it would have access.
2. Security contexts for libvirt managed objects
virDomainPtr: Already embedded in XML, unless using dynamic labelling in which case context is assigned at startup.
virNetworkPtr: No existing security context, nor any object on disk that could be used. Follow example of domains and embed <seclabel> in the XML. Assign unique MCS category per network and ensure that daemons launched per network (dnsmasq, radvd) inherit the MCS category.
virSecretPtr: No existing security context. Secrets may be associated with disk paths for VMs. Could copy the security context of the guests and apply it to the secret, or have a dedicated type svirt_secret_t and just copy the MCS category. Hard to make it work for guests with dynamic MCS assignment.
virStoragePoolPtr: No existing security context. Some pool types have objects existing on the host filesystem eg SCSI HBAs have a directory in sysfs, filesystem dirs have a directory somewhere, LVM has directory for the volume group in /dev. Other pool types have no object on disk anywhere convenient. eg Sheepdog. Other pool types only have an object on disk when the pool is active (eg iSCSI, NFS). So there is nothing to use for API checks when the pool is inactive.
Likely have to ignore whatever associated resource is on disk and just store a security context in the XML config as with virDomainPtr/virNetworkPtr.
virStorageVolPtr: Currently reports the SELinux security label associated with the file on disk. Not all pool types neccessarily have volumes with a corresponding file on disks (eg Sheepdog).
virNodeDevicePtr: No existing security context. Most data comes from udev or HAL databases, though ultimately much is available in sysfs.
When detaching PCI devices from host drivers, files in sysfs are used. When creating/deleting NPIV adapters sysfs is used. Thus could use sysfs file labels for AVC checks ?
virConnectPtr: All host level APIs for which there is no other object aside from the nebulous concept of the 'host'. APIs are all readonly, eg query host capabilities, query free memory, CPU stats, etc. What if we gain APIs to make write calls.
virInterfacePtr: No existing security context. Currently using netcf to get data from /etc/sysconfig/network-scripts/ifcfg-XXX files, but can't assume those file names since that is Fedora/RHEL specific. Might not even use netcf if it talks directly to network manager. Does netcf need to expose a security label based on the ifcfg-XXX file ?
3. Security labelling config modes
When creating a guest the following XML snippets can be used.
a. Default type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='dynamic' relabel='yes'/>
b. Custom type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='hybrid' relabel='yes'> <label>system_u:system_r:mysvirt_t</label> <imagelabel>system_u:object_r:mysvirt_image_t</imagelabel> </seclabel>
Yes this would be cool, although I am not sure you need an image label, since the MCS separation would still work on svirt_image_t. Would make policy writing easier and selection easier if you did not change the type of the image file. I would at least allow for the admin to not specify a image label.
c. Default type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='dynamic' relabel='no'/>
Does this mode make any sense, since admin doesn't know MCS category upfront ? Possibly only useful if the guest only has readonly disks.
But you don't relabel on readonly correct, since this is a shared resource. I would say this would not be used.
d. Custom type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='hybrid' relabel='no'> <label>system_u:system_r:mysvirt_t</label> </seclabel>
Same question about whether it makes sense
I don't think this makes sense.
e. Custom type, static MCS, auto relabelling
<seclabel type='selinux' mode='static' relabel='yes'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> <imagelabel>system_u:system_r:mysvirt_image_t:s0:c123,c456</imagelabel> </seclabel>
This is fine, not sure it is legal in MLS world. Although I guess we could change the label to SystemHigh when not in use.
f. Custom type, static MCS, no relabelling
<seclabel type='selinux' mode='static' relabel='no'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> </seclabel>
We have this now, this is static labeling.
4. Time at which to apply checks / source context
It would be desirable to restrict the ability to use automatic file relabelling within the policy. If a client application defines a guest with the 'relabel=yes' attribute set, at what time should this usage be validated ?
Validate at the time the guest is defined ? This ensures the app defining the guest is suitably privileged, but the file labels might be changed by the time the guest starts.
Validate at the time the guest is started ? This minimises the window between access check being performed, and libvirtd actually performing the relabel operation. The app starting the guest might be different from the one defining the guest though ?
Check at both define + start time ?
Probably most sane.
What source security context should we use when performing autostart of virtual machines ? Normally when starting a VM, the check would be performed using the context of the client invoking the start API, but there is no such client when autostart occurs.
libselinux default.
Should we instead perform a 'start' operation check whenever the 'autostart' flag is turned on by a client ? Or check the autostart operation against some generic source context ?
I think we leave this in the default_context file. One last thing to think about is since libvirt can now be run under the users context, in certain situations, libvirt should examine the range of MLS/MCS labels associated with it and make sure that it can only assign MCS labels within this range. For example if I am a user running as staff_t:s0-s0:c500 libvirt should only pick random labels between 0-500. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3tIaIACgkQrlYvE4MpobMc3ACfcDqjO+dns9V+zGr1l1h0qbNe jcsAoMuSheEzYSKWbPd0/9zr+zn6PndG =SttH -----END PGP SIGNATURE-----
On Mon, Jun 06, 2011 at 02:51:15PM -0400, Daniel J Walsh wrote:
On 06/06/2011 10:41 AM, Daniel P. Berrange wrote:
Technical Notes / Issues ------------------------
1. Adding new SELinux security classes / access vectors
The selinux security classes are defined in /usr/include/selinux/flask.h and access vectors in /usr/include/selinux/av_permissions.h Both of these files are automatically by a script in the selinux reference policy code '$serefpolicy/policy/flask/flask.py'. The master data files are in the same directory, 'access_vectors' and 'security_classes'. Once generated, the headers need to be manually copied into the libselinux package sources.
You do not need to do this anymore. libselinux does not care about the access vectors, they are named in your application.Well
AFAICT, when I invoke avc_has_perm(), the security_class_t and access_vector_t parameters are integer constants that come from selinux/flask.h and selinux/av_permissions.h respectively. While I could just pick some unused numbers myself and hardcode in the libvirt source, it seems like it is better to have them recorded in those header files deployed by libselinux, so libvirt's usage doesn't clash with some other future app.
3. Security labelling config modes
When creating a guest the following XML snippets can be used.
a. Default type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='dynamic' relabel='yes'/>
b. Custom type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='hybrid' relabel='yes'> <label>system_u:system_r:mysvirt_t</label> <imagelabel>system_u:object_r:mysvirt_image_t</imagelabel> </seclabel>
Yes this would be cool, although I am not sure you need an image label, since the MCS separation would still work on svirt_image_t. Would make policy writing easier and selection easier if you did not change the type of the image file.
I would at least allow for the admin to not specify a image label.
Yes, now that you mention it, including the imagelabel does seem redundant here. Once we can have multiple different base labels, should we control uniqueness just on the MCS category, or the full label. I believe we still want the former. eg, we should forbid two different guests to run: 'myfirst_svirt_t:c123,435' 'myother_svirt_t:c123,435'
c. Default type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='dynamic' relabel='no'/>
Does this mode make any sense, since admin doesn't know MCS category upfront ? Possibly only useful if the guest only has readonly disks.
But you don't relabel on readonly correct, since this is a shared resource. I would say this would not be used.
We do actually relabel readonly content, but to the shared label (if it doesn't already have the right shared label).
d. Custom type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='hybrid' relabel='no'> <label>system_u:system_r:mysvirt_t</label> </seclabel>
Same question about whether it makes sense
I don't think this makes sense.
e. Custom type, static MCS, auto relabelling
<seclabel type='selinux' mode='static' relabel='yes'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> <imagelabel>system_u:system_r:mysvirt_image_t:s0:c123,c456</imagelabel> </seclabel>
This is fine, not sure it is legal in MLS world. Although I guess we could change the label to SystemHigh when not in use.
Yep, or just have MLS policy block this scenario.
f. Custom type, static MCS, no relabelling
<seclabel type='selinux' mode='static' relabel='no'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> </seclabel>
We have this now, this is static labeling.
Correct, options a. and f. are the two current configs we support.
One last thing to think about is since libvirt can now be run under the users context, in certain situations, libvirt should examine the range of MLS/MCS labels associated with it and make sure that it can only assign MCS labels within this range.
For example if I am a user running as
staff_t:s0-s0:c500
libvirt should only pick random labels between 0-500.
Ah, interesting point. Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/08/2011 06:34 AM, Daniel P. Berrange wrote:
On Mon, Jun 06, 2011 at 02:51:15PM -0400, Daniel J Walsh wrote:
On 06/06/2011 10:41 AM, Daniel P. Berrange wrote:
Technical Notes / Issues ------------------------
1. Adding new SELinux security classes / access vectors
The selinux security classes are defined in /usr/include/selinux/flask.h and access vectors in /usr/include/selinux/av_permissions.h Both of these files are automatically by a script in the selinux reference policy code '$serefpolicy/policy/flask/flask.py'. The master data files are in the same directory, 'access_vectors' and 'security_classes'. Once generated, the headers need to be manually copied into the libselinux package sources.
You do not need to do this anymore. libselinux does not care about the access vectors, they are named in your application.Well
AFAICT, when I invoke avc_has_perm(), the security_class_t and access_vector_t parameters are integer constants that come from selinux/flask.h and selinux/av_permissions.h respectively. While I could just pick some unused numbers myself and hardcode in the libvirt source, it seems like it is better to have them recorded in those header files deployed by libselinux, so libvirt's usage doesn't clash with some other future app.
There are calls now that ask the kernel for the correct numbers. man security_av_string
3. Security labelling config modes
When creating a guest the following XML snippets can be used.
a. Default type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='dynamic' relabel='yes'/>
b. Custom type, dynamic MCS, automatic relabelling
<seclabel type='selinux' mode='hybrid' relabel='yes'> <label>system_u:system_r:mysvirt_t</label> <imagelabel>system_u:object_r:mysvirt_image_t</imagelabel> </seclabel>
Yes this would be cool, although I am not sure you need an image label, since the MCS separation would still work on svirt_image_t. Would make policy writing easier and selection easier if you did not change the type of the image file.
I would at least allow for the admin to not specify a image label.
Yes, now that you mention it, including the imagelabel does seem redundant here.
Once we can have multiple different base labels, should we control uniqueness just on the MCS category, or the full label. I believe we still want the former.
eg, we should forbid two different guests to run:
'myfirst_svirt_t:c123,435' 'myother_svirt_t:c123,435'
Yes I would keep one table of MCS Strings unique and never allow two process the same label.
c. Default type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='dynamic' relabel='no'/>
Does this mode make any sense, since admin doesn't know MCS category upfront ? Possibly only useful if the guest only has readonly disks.
But you don't relabel on readonly correct, since this is a shared resource. I would say this would not be used.
We do actually relabel readonly content, but to the shared label (if it doesn't already have the right shared label).
Ok
d. Custom type, dynamic MCS, no relabelling
<seclabel type='selinux' mode='hybrid' relabel='no'> <label>system_u:system_r:mysvirt_t</label> </seclabel>
Same question about whether it makes sense
I don't think this makes sense.
e. Custom type, static MCS, auto relabelling
<seclabel type='selinux' mode='static' relabel='yes'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> <imagelabel>system_u:system_r:mysvirt_image_t:s0:c123,c456</imagelabel> </seclabel>
This is fine, not sure it is legal in MLS world. Although I guess we could change the label to SystemHigh when not in use.
Yep, or just have MLS policy block this scenario.
f. Custom type, static MCS, no relabelling
<seclabel type='selinux' mode='static' relabel='no'> <label>system_u:system_r:mysvirt_t:s0:c123,c456</label> </seclabel>
We have this now, this is static labeling.
Correct, options a. and f. are the two current configs we support.
One last thing to think about is since libvirt can now be run under the users context, in certain situations, libvirt should examine the range of MLS/MCS labels associated with it and make sure that it can only assign MCS labels within this range.
For example if I am a user running as
staff_t:s0-s0:c500
libvirt should only pick random labels between 0-500.
Ah, interesting point.
Daniel
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk3ww3AACgkQrlYvE4MpobND+wCgoI2cK6qFOLspFe+MltnlqjwA hmwAnAuYytuZMf2tDPJphrQJ16IxXJjq =ShL0 -----END PGP SIGNATURE-----
On Mon, Jun 06, 2011 at 03:41:23PM +0100, Daniel P. Berrange wrote:
13. Write policy to confine targetted applications like virt-top, virt-mem.
It's called 'virt-dmesg' now :-) If I'm understand this all correctly, changes are not required to virt-top and virt-dmesg themselves. Instead all changes are confined to selinux-policy? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
On Wed, Jun 08, 2011 at 04:54:34PM +0100, Richard W.M. Jones wrote:
On Mon, Jun 06, 2011 at 03:41:23PM +0100, Daniel P. Berrange wrote:
13. Write policy to confine targetted applications like virt-top, virt-mem.
It's called 'virt-dmesg' now :-)
If I'm understand this all correctly, changes are not required to virt-top and virt-dmesg themselves. Instead all changes are confined to selinux-policy?
Yeah, it shouldn't need any code changes, unless the app is doing something really crazy, which is somewhat unlikely Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Mon, 2011-06-06 at 15:41 +0100, Daniel P. Berrange wrote:
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism.
Are we reinventing a lot of PolicyKit? I don't think policykit does a good job of using SELinux but it does attempt to solve most of the same problem you are attempting to solve here. I just want to make sure it was looked at, even if I like the approach you are taking here more... -Eric
On Thu, 2011-06-09 at 11:15 -0400, Eric Paris wrote:
On Mon, 2011-06-06 at 15:41 +0100, Daniel P. Berrange wrote:
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism.
Are we reinventing a lot of PolicyKit? I don't think policykit does a good job of using SELinux but it does attempt to solve most of the same problem you are attempting to solve here. I just want to make sure it was looked at, even if I like the approach you are taking here more...
I've not had time to dig deep into this, but a concern I had is how this might affect other security drivers (in my case, specifically AppArmor, but DAC alone might also be something to think about as well as any future drivers like for SMACK or Tomoyo). Using something like PolicyKit, if it is appropriate, could allow non-SElinux drivers to benefit as well. -- Jamie Strandboge | http://www.canonical.com
On Thu, Jun 09, 2011 at 11:41:10AM -0500, Jamie Strandboge wrote:
On Thu, 2011-06-09 at 11:15 -0400, Eric Paris wrote:
On Mon, 2011-06-06 at 15:41 +0100, Daniel P. Berrange wrote:
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism.
Are we reinventing a lot of PolicyKit? I don't think policykit does a good job of using SELinux but it does attempt to solve most of the same problem you are attempting to solve here. I just want to make sure it was looked at, even if I like the approach you are taking here more...
I've not had time to dig deep into this, but a concern I had is how this might affect other security drivers (in my case, specifically AppArmor, but DAC alone might also be something to think about as well as any future drivers like for SMACK or Tomoyo). Using something like PolicyKit, if it is appropriate, could allow non-SElinux drivers to benefit as well.
I already addressed the issue of non-SELinux users in my original mail: [quote] 9. Create a simple impl of the access control APIs which defines roles for groups of user identities, and grants privileges to each role based on the operation names. This allows for simple testing of internal infrastructure, and an RBAC mechanism for users who lack SELinux in their OS. [/quote] Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, Jun 09, 2011 at 11:15:48AM -0400, Eric Paris wrote:
On Mon, 2011-06-06 at 15:41 +0100, Daniel P. Berrange wrote:
What follows is a document outlining some thoughts I've been having on extending sVirt to allow confinement of applications which talk to libvirtd on the host, primarily focusing on use of SELinux, but also allowing a simple non-SElinux RBAC mechanism.
Are we reinventing a lot of PolicyKit? I don't think policykit does a good job of using SELinux but it does attempt to solve most of the same problem you are attempting to solve here. I just want to make sure it was looked at, even if I like the approach you are taking here more...
PolicyKit sounds nice in theory, but in practice I don't believe it can be made to support what I'm proposing. In policykit authorization is performed for a tuple (action, subject) In this, 'action' is a string that identifies the operation being requested, while 'subject' is the client app being checked (either a local UNIX process/user ID or a DBus system bus name in current polkit). libvirt wants to be able to check authorization on a finer level of granularity (action, subject, object) where, action is again just a string identifying the operation, subject is the client app (a local UNIX process/user ID, or a local or remote SELinux context, and 'object' is a managed object like a domain, network, storage pool, identified by UUID, name and/or SELinux context. Polkit 'action' strings must be registered statically in text files in /usr/share/polkit-1, so you can't just munge a object identifier into the 'action' string to get finer grained auth checking. If we used polkit for auth in libvirt, there is no obvious way to scope the checks to individual objects, and no way to include SELinux contexts in the authorization checks. I'm also not convinced that polkit has a scalable architecture when we consider a need to perform several 100's (or even 1000's) of authorization checks in a single API call. Each polkit check requires passing messages from libvirt to DBus system bus to the polkit daemon, and then back again, as opposed to just one or two kernel calls to use something like avc_has_perm() in SELinux. So while, we could, add policy kit support at the granularity of (action, subject) for libvirt API calls, I don't think that could replace the need to provide the fine grained authorization mechanism I describe here. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
participants (5)
-
Daniel J Walsh -
Daniel P. Berrange -
Eric Paris -
Jamie Strandboge -
Richard W.M. Jones