 76ca4b58c2
			
		
	
	
		76ca4b58c2
		
	
	
	
	
		
			
			I found that there are many spelling errors in the comments of qemu, so I used the spellcheck tool to check the spelling errors and finally found some spelling errors in the docs folder. Signed-off-by: zhaolichang <zhaolichang@huawei.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Message-Id: <20200917075029.313-4-zhaolichang@huawei.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
		
			
				
	
	
		
			111 lines
		
	
	
		
			3.4 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
			
		
		
	
	
			111 lines
		
	
	
		
			3.4 KiB
		
	
	
	
		
			ReStructuredText
		
	
	
	
	
	
| =====
 | |
| D-Bus
 | |
| =====
 | |
| 
 | |
| Introduction
 | |
| ============
 | |
| 
 | |
| QEMU may be running with various helper processes involved:
 | |
|  - vhost-user* processes (gpu, virtfs, input, etc...)
 | |
|  - TPM emulation (or other devices)
 | |
|  - user networking (slirp)
 | |
|  - network services (DHCP/DNS, samba/ftp etc)
 | |
|  - background tasks (compression, streaming etc)
 | |
|  - client UI
 | |
|  - admin & cli
 | |
| 
 | |
| Having several processes allows stricter security rules, as well as
 | |
| greater modularity.
 | |
| 
 | |
| While QEMU itself uses QMP as primary IPC (and Spice/VNC for remote
 | |
| display), D-Bus is the de facto IPC of choice on Unix systems. The
 | |
| wire format is machine friendly, good bindings exist for various
 | |
| languages, and there are various tools available.
 | |
| 
 | |
| Using a bus, helper processes can discover and communicate with each
 | |
| other easily, without going through QEMU. The bus topology is also
 | |
| easier to apprehend and debug than a mesh. However, it is wise to
 | |
| consider the security aspects of it.
 | |
| 
 | |
| Security
 | |
| ========
 | |
| 
 | |
| A QEMU D-Bus bus should be private to a single VM. Thus, only
 | |
| cooperative tasks are running on the same bus to serve the VM.
 | |
| 
 | |
| D-Bus, the protocol and standard, doesn't have mechanisms to enforce
 | |
| security between peers once the connection is established. Peers may
 | |
| have additional mechanisms to enforce security rules, based for
 | |
| example on UNIX credentials.
 | |
| 
 | |
| The daemon can control which peers can send/recv messages using
 | |
| various metadata attributes, however, this is alone is not generally
 | |
| sufficient to make the deployment secure.  The semantics of the actual
 | |
| methods implemented using D-Bus are just as critical. Peers need to
 | |
| carefully validate any information they received from a peer with a
 | |
| different trust level.
 | |
| 
 | |
| dbus-daemon policy
 | |
| ------------------
 | |
| 
 | |
| dbus-daemon can enforce various policies based on the UID/GID of the
 | |
| processes that are connected to it. It is thus a good idea to run
 | |
| helpers as different UID from QEMU and set appropriate policies.
 | |
| 
 | |
| Depending on the use case, you may choose different scenarios:
 | |
| 
 | |
|  - Everything the same UID
 | |
| 
 | |
|    - Convenient for developers
 | |
|    - Improved reliability - crash of one part doesn't take
 | |
|      out entire VM
 | |
|    - No security benefit over traditional QEMU, unless additional
 | |
|      unless additional controls such as SELinux or AppArmor are
 | |
|      applied
 | |
| 
 | |
|  - Two UIDs, one for QEMU, one for dbus & helpers
 | |
| 
 | |
|    - Moderately improved user based security isolation
 | |
| 
 | |
|  - Many UIDs, one for QEMU one for dbus and one for each helpers
 | |
| 
 | |
|    - Best user based security isolation
 | |
|    - Complex to manager distinct UIDs needed for each VM
 | |
| 
 | |
| For example, to allow only ``qemu`` user to talk to ``qemu-helper``
 | |
| ``org.qemu.Helper1`` service, a dbus-daemon policy may contain:
 | |
| 
 | |
| .. code:: xml
 | |
| 
 | |
|   <policy user="qemu">
 | |
|      <allow send_destination="org.qemu.Helper1"/>
 | |
|      <allow receive_sender="org.qemu.Helper1"/>
 | |
|   </policy>
 | |
| 
 | |
|   <policy user="qemu-helper">
 | |
|      <allow own="org.qemu.Helper1"/>
 | |
|   </policy>
 | |
| 
 | |
| 
 | |
| dbus-daemon can also perform SELinux checks based on the security
 | |
| context of the source and the target. For example, ``virtiofs_t``
 | |
| could be allowed to send a message to ``svirt_t``, but ``virtiofs_t``
 | |
| wouldn't be allowed to send a message to ``virtiofs_t``.
 | |
| 
 | |
| See dbus-daemon man page for details.
 | |
| 
 | |
| Guidelines
 | |
| ==========
 | |
| 
 | |
| When implementing new D-Bus interfaces, it is recommended to follow
 | |
| the "D-Bus API Design Guidelines":
 | |
| https://dbus.freedesktop.org/doc/dbus-api-design.html
 | |
| 
 | |
| The "org.qemu.*" prefix is reserved for services implemented &
 | |
| distributed by the QEMU project.
 | |
| 
 | |
| QEMU Interfaces
 | |
| ===============
 | |
| 
 | |
| :doc:`dbus-vmstate`
 |