AppArmor support for TPM emulator; was:Re: [PATCH 00/12] Add support for TPM emulator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 05/23/2018 08:07 AM, John Ferlan wrote:

On 05/22/2018 04:44 PM, Stefan Berger wrote:
This series of patches adds support for the TPM emulator backend that
is available in QEMU and based on swtpm + libtpms. It allows to attach a
TPM 1.2 or 2 to a QEMU VM. sVirt labels are used for labeling the swtpm
process, its Unix socket, and log file with the same label that the
QEMU process gets. Besides that swtpm is added to the emulator cgroup to
restrict its CPU usage.

The device XML can be changed from a TPM 1.2 to a TPM 2 and back to a
TPM 1.2. The device state is not removed during those changes but only
when the domain is undefined.

The swtpm needs persistent storage to store its state. For that I am
using the uuid of the VM as part of the path since the name of the VM
can be changed. Logfiles, PID files, and socket names are based on the
name of the VM, though.

   Stefan

v5->v6:
   - Addressed John Ferlan's comments
   - rebased on latest tip
   - Added patch 12.

v4->v5:
   - Addressed John Ferlan's, Boris Fiuczysnki's and Marc Hartmayer's comments
   - rebased on latest tip

v3->v4:
   - Addressed John Ferlan's comments
   - Fixed bugs I found while testing
   - rebased on latest tip

Stefan Berger (12):
   conf: Add support for external swtpm TPM emulator to domain XML
   qemu: Extend QEMU capabilities with 'tpm-emulator'
   util: Implement virFileChownFiles()
   security: Add DAC and SELinux security for tpm-emulator
   qemu: Extend qemu_conf with tpm-emulator support
   qemu: Extend QEMU with external TPM support
   qemu: Add support for external swtpm TPM emulator
   tests: Add test cases for external swtpm TPM emulator
   security: Label the external swtpm with SELinux labels
   conf: Add support for choosing emulation of a TPM 2
   qemu: Add swtpm to emulator cgroup
   news: Update news with new TPM emulator feature

  docs/formatdomain.html.in                          |  43 +
  docs/news.xml                                      |   9 +
  docs/schemas/domaincommon.rng                      |  17 +
  libvirt.spec.in                                    |   2 +
  src/conf/domain_audit.c                            |   2 +
  src/conf/domain_conf.c                             |  53 +-
  src/conf/domain_conf.h                             |  12 +
  src/libvirt_private.syms                           |   3 +
  src/qemu/Makefile.inc.am                           |  10 +
  src/qemu/libvirtd_qemu.aug                         |   5 +
  src/qemu/qemu.conf                                 |   8 +
  src/qemu/qemu_capabilities.c                       |   5 +
  src/qemu/qemu_capabilities.h                       |   1 +
  src/qemu/qemu_cgroup.c                             |  36 +
  src/qemu/qemu_cgroup.h                             |   2 +
  src/qemu/qemu_command.c                            |  34 +-
  src/qemu/qemu_conf.c                               |  43 +
  src/qemu/qemu_conf.h                               |   6 +
  src/qemu/qemu_domain.c                             |   3 +
  src/qemu/qemu_extdevice.c                          | 180 ++++
  src/qemu/qemu_extdevice.h                          |  59 ++
  src/qemu/qemu_process.c                            |  16 +
  src/qemu/qemu_security.c                           |  69 ++
  src/qemu/qemu_security.h                           |  11 +
  src/qemu/qemu_tpm.c                                | 946 +++++++++++++++++++++
  src/qemu/qemu_tpm.h                                |  56 ++
  src/qemu/test_libvirtd_qemu.aug.in                 |   2 +
  src/security/security_dac.c                        |   7 +
  src/security/security_driver.h                     |   7 +
  src/security/security_manager.c                    |  36 +
  src/security/security_manager.h                    |   6 +
  src/security/security_selinux.c                    | 172 ++++
  src/security/security_stack.c                      |  40 +
  src/util/virfile.c                                 |  55 ++
  src/util/virfile.h                                 |   3 +
  tests/qemucapabilitiesdata/caps_2.11.0.s390x.xml   |   1 +
  tests/qemucapabilitiesdata/caps_2.12.0.aarch64.xml |   1 +
  tests/qemucapabilitiesdata/caps_2.12.0.ppc64.xml   |   1 +
  tests/qemucapabilitiesdata/caps_2.12.0.s390x.xml   |   1 +
  tests/qemucapabilitiesdata/caps_2.12.0.x86_64.xml  |   1 +
  .../tpm-emulator-tpm2.x86_64-latest.args           |  33 +
  tests/qemuxml2argvdata/tpm-emulator-tpm2.xml       |  30 +
  .../tpm-emulator.x86_64-latest.args                |  33 +
  tests/qemuxml2argvdata/tpm-emulator.xml            |  30 +
  tests/qemuxml2argvtest.c                           |  16 +-
  tests/qemuxml2xmloutdata/tpm-emulator-tpm2.xml     |  34 +
  tests/qemuxml2xmloutdata/tpm-emulator.xml          |  34 +
  tests/qemuxml2xmltest.c                            |   1 +
  48 files changed, 2165 insertions(+), 10 deletions(-)
  create mode 100644 src/qemu/qemu_extdevice.c
  create mode 100644 src/qemu/qemu_extdevice.h
  create mode 100644 src/qemu/qemu_tpm.c
  create mode 100644 src/qemu/qemu_tpm.h
  create mode 100644 tests/qemuxml2argvdata/tpm-emulator-tpm2.x86_64-latest.args
  create mode 100644 tests/qemuxml2argvdata/tpm-emulator-tpm2.xml
  create mode 100644 tests/qemuxml2argvdata/tpm-emulator.x86_64-latest.args
  create mode 100644 tests/qemuxml2argvdata/tpm-emulator.xml
  create mode 100644 tests/qemuxml2xmloutdata/tpm-emulator-tpm2.xml
  create mode 100644 tests/qemuxml2xmloutdata/tpm-emulator.xml

This all looks good to me - thanks for the news.xml adjustment. Barring
anyone else making a late/additional review - I will look to push the
series later on today.

Thanks.

As mentioned, I will need to follow up with AppArmor support. What I am currently experimenting with is a subprofile of the libvirt profile. The problem with it is it's 'suboptimal' in terms of 'unspecific' paths containing wild-cards so that this single sub profile can accommodate the paths of all domains. This profile is static and not dynamically generated.

diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
index 3102cab382..dcab4feb6c 100644
--- a/examples/apparmor/usr.sbin.libvirtd
+++ b/examples/apparmor/usr.sbin.libvirtd
@@ -126,4 +126,15 @@

    /usr/{lib,lib64,lib/qemu,libexec}/qemu-bridge-helper rmix,
   }
+  /usr/bin/swtpm Cx -> usr_bin_swtpm,
+  profile usr_bin_swtpm flags=(complain) {
+    #include <abstractions/base>
+
+    /usr/bin/swtpm rm,
+
+    /run/libvirt/qemu/swtpm/*-swtpm.pid rw,
+    /run/libvirt/qemu/swtpm/*-swtpm.sock w,
+    /var/log/swtpm/libvirt/qemu/*-swtpm.log w,
+ /var/lib/libvirt/swtpm/[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*/{tpm1.2,tpm2}/{tpm,tpm2}-00.permall rw,
+  }
 }


A better solution would be to extend the QEMU domain profile with these additional paths, which, as a side-effect, would give a QEMU instance access to these paths as well. Basically QEMU and swtpm would share that profile. To good thing is we can use specific paths (no wild cards) for the files that the swtpm needs to access.

Yet a stricter solution would be to dynamically create a profile specifically for the swtpm that contains only the necessary paths. Though I think the code in src/security/security_apparmor.c is not prepared for that and it may end up being a bigger undertaking.

Anyone who would be willing to give an opinion on the latter two cases ? I am cc'ing Christian Ehrhard who seems to have worked on AppArmor related code.

   Stefan


John


--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list




[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux