208
208
Thus, if a vendor / distributor has configured their libvirt package
209
209
to run as 'qemu' by default, a number of changes will be required
210
210
before an administrator can change a host to run guests as root.
211
In particular it will be neccessary to change ownership on the
211
In particular it will be necessary to change ownership on the
212
212
directories <code>/var/run/libvirt/qemu/</code>,
213
213
<code>/var/lib/libvirt/qemu/</code> and
214
214
<code>/var/cache/libvirt/qemu/</code> back to root, in addition
296
296
file can be used to change the setting to <code>security_driver="none"</code>
299
<h3><a name="securitysvirtaa">AppArmor sVirt confinement</a></h3>
302
When using basic AppArmor protection for the libvirtd daemon and
303
QEMU virtual machines, the intention is to protect the host OS
304
from a compromised virtual machine process. There is no protection
309
The AppArmor sVirt protection for QEMU virtual machines builds on
310
this basic level of protection, to also allow individual guests to
311
be protected from each other.
315
In the sVirt model, if a profile is loaded for the libvirtd daemon,
316
then each <code>qemu:///system</code> QEMU virtual machine will have
317
a profile created for it when the virtual machine is started if one
318
does not already exist. This generated profile uses a profile name
319
based on the UUID of the QEMU virtual machine and contains rules
320
allowing access to only the files it needs to run, such as its disks,
321
pid file and log files. Just before the QEMU virtual machine is
322
started, the libvirtd daemon will change into this unique profile,
323
preventing the QEMU process from accessing any file resources that
324
are present in another QEMU process or the host machine.
328
The AppArmor sVirt implementation is flexible in that it allows an
329
administrator to customize the template file in
330
<code>/etc/apparmor.d/libvirt/TEMPLATE</code> for site-specific
331
access for all newly created QEMU virtual machines. Also, when a new
332
profile is generated, two files are created:
333
<code>/etc/apparmor.d/libvirt/libvirt-<uuid></code> and
334
<code>/etc/apparmor.d/libvirt/libvirt-<uuid>.files</code>. The
335
former can be fine-tuned by the administrator to allow custom access
336
for this particular QEMU virtual machine, and the latter will be
337
updated appropriately when required file access changes, such as when
338
a disk is added. This flexibility allows for situations such as
339
having one virtual machine in complain mode with all others in
344
While users can define their own AppArmor profile scheme, a typical
345
configuration will include a profile for <code>/usr/sbin/libvirtd</code>,
346
<code>/usr/lib/libvirt/virt-aa-helper</code> (a helper program which the
347
libvirtd daemon uses instead of manipulating AppArmor directly), and
348
an abstraction to be included by <code>/etc/apparmor.d/libvirt/TEMPLATE</code>
349
(typically <code>/etc/apparmor.d/abstractions/libvirt-qemu</code>).
350
An example profile scheme can be found in the examples/apparmor
351
directory of the source distribution.
355
If the sVirt security model is active, then the node capabilities
356
XML will include its details. If a virtual machine is currently
357
protected by the security model, then the guest XML will include
358
its assigned profile name. If enabled at compile time, the sVirt
359
security model will be activated if AppArmor is available on the host
360
OS and a profile for the libvirtd daemon is loaded when libvirtd is
361
started. To disable sVirt, and revert to the basic level of AppArmor
362
protection (host protection only), the <code>/etc/libvirt/qemu.conf</code>
363
file can be used to change the setting to <code>security_driver="none"</code>.
300
367
<h3><a name="securityacl">Cgroups device ACLs</a></h3>
added
removed
docs/drvqemu.html.in
