libvirt should not use user tss for swtpm

Bug #1948880 reported by Steve Langasek
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libvirt (Ubuntu)
Fix Released
High
Christian Ehrhardt 

Bug Description

libvirt encodes 'tss' as the user (and group) to use when running swtpm.

This overloads the tss user, which is already used by the tpm-udev package for controlling access to the host's *physical* TPM devices, which should not be conflated with virtual TPMs.

I suggest libvirt should instead use a user/group 'swtpm', that would be provided by the swtpm-tools package.

Related branches

tags: added: server-next
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Steve,
after just "agreeing and tagging" before I have done an initial check on the case.

Tasks:

Similar to the .spec file dir ownership needs to be set:
 %dir %attr(0730, tss, tss) %{_localstatedir}/log/swtpm/libvirt/qemu/

We might want to look at the ALL swtpm related directories being:
       swtpmLogDir: /var/log/swtpm/libvirt/qemu
     swtpmStateDir: /run/libvirt/qemu/swtpm
   swtpmStorageDir: /var/lib/libvirt/swtpm

Log and storage are static, but state is /run and thereby needs to be recreated each time.

The actually used user is encoded in
  /etc/libvirt/qemu.conf

# User for the swtpm TPM Emulator
#
# Default is 'tss'; this is the same user that tcsd (TrouSerS) installs
# and uses; alternative is 'root'
#
#swtpm_user = "tss"
#swtpm_group = "tss"

And we might want to switch that default by changing the config at PKG build time.

That most likely also needs a change in the build time self tests and augeas usage at
 src/qemu/test_libvirtd_qemu.aug.in
   113 { "swtpm_user" = "tss" }
   114 { "swtpm_group" = "tss" }

Finally, so far it didn't exists but right now we should consider adding swtpm as a suggests.
Once things are more complete and swtpm MIR is ready (bug 1948748) we can bump this to a recommends then.

Next steps once I really get to this (after sprint week):
 - get a PPA set up with the changes
 - run various tests with/without PPA
 - upload to Ubuntu
 - clarify potential Debian usage
 - bump to Recommends once MIR is ready

Changed in libvirt (Ubuntu):
status: New → Triaged
importance: Undecided → High
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

@Steve - do you plan to upload the same to Debian so that I would change libvirt there as well?

Utkarsh Gupta (utkarsh)
Changed in libvirt (Ubuntu):
assignee: nobody → Utkarsh Gupta (utkarsh)
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Note: this will have multiple issues.
First of all user/group 'swtpm' are NOT YET provided by swtpm packages (that was a "would" in the bug description).

But furthermore it seems that swtpm-tools will have a harder time to be promoted to main than swtpm itself. I've spawned bug 1949060 to discuss/cover that (FYI - found while MIR reviewing bug 1948748).

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

@Utkarsh - it would still be a great exercise to get the libvirt changes all prepared and test on manually created swtpm users. Then whenever this overall topic further resolves we are ready for it.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

@utkarsh: In the dependencies, please use "swtpm-tools" not "swtpm" as it will need binaries from there. The most recent upload to swtpm implemented the user we needed, so work on this is now unblocked.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

It seems state and storage dir seem to be created on demand, not package owned but existing on a live system. I'll see if that is true (and what user it applied) when testing the builds.

The rest was straight forward and builds right now.
Initial (untested) branch and PPA available:
PPA: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4710
MR: https://code.launchpad.net/~paelzer/ubuntu/+source/libvirt/+git/libvirt/+merge/411755

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI
libvirt regressed in release and is a FTBFS on s390x.
 88/162 virdrivermoduletest FAIL 0.04s exit status 1
128/162 storagepoolxml2argvtest FAIL 0.04s exit status 1
129/162 storagepoolxml2xmltest FAIL 0.03s exit status 1
132/162 virstoragetest FAIL 0.03s exit status 1
Unfortunately this will stall this a bit.

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Paths if used with libvirt before the upgrade

$ sudo apt install swtpm-tools
# Add to the guest a tpm2 emulation
    <tpm model='tpm-tis'>
      <backend type='emulator' version='2.0'/>
    </tpm>

It is important to realize that with the switch of swtpm-tools itself
to swtpm:swtpm broke usage with libvirt (up to this upload).

That is because /var/lib/dpkg/info/swtpm-tools.postinst now sets

$ sudo ls -laFd /var/lib/swtpm-localca
drwxr-x--- 2 swtpm root 4096 Nov 15 13:38 /var/lib/swtpm-localca/

Due to that the default config of libvirt (that was tss:tss) now fails via

$ virsh start f-tpm
error: Failed to start domain 'f-tpm'
error: internal error: Could not run '/usr/bin/swtpm_setup'. exitstatus: 1;
Check error log '/var/log/swtpm/libvirt/qemu/f-tpm-swtpm.log' for details.

ubuntu@node-horsea:~$ sudo cat /var/log/swtpm/libvirt/qemu/f-tpm-swtpm.log
Starting vTPM manufacturing as tss:tss @ Mon 15 Nov 2021 01:38:53 PM UTC
Successfully created RSA 2048 EK with handle 0x81010001.
  Invoking /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek df06f941e4c58e2c043407c1eb2a5afa6825ee93362ebe33e8ada87986bd04bb356ee64d02625f9cb234bf13afbd4d5e93456ad24dccd1b3083b063d4098573045dd1f8c73ee1ca8860f2f5f211ccd6336774388202099dd6117e38ebe162a34e7af024f6eac15c9683979ef4f4fbe5bda39284d209bfe32897ad87df062382e3ce6a070cfbc325223d6e12f366bb115fbadf78e66790d6e04f5d8f27f6e8ca431bb779fe8b67e6707ceb36de8540838f2acab6535fcf1739e7b51f22d4d774c17c1e56d86d64e52319d5303ab7c8e47303c359858ace7b282d6ff696930a595db20202884417fe19b00d2272966979bedc7c36e678fbaf26be84fdfa7059ddf --dir /var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17/tpm2 --logfile /var/log/swtpm/libvirt/qemu/f-tpm-swtpm.log --vmid f-tpm:65113265-34d6-4358-b562-4d7508d6ff17 --tpm-spec-family 2.0 --tpm-spec-level 0 --tpm-spec-revision 164 --tpm-manufacturer id:00001014 --tpm-model swtpm --tpm-version id:20191023 --tpm2 --configfile /etc/swtpm-localca.conf --optsfile /etc/swtpm-localca.options
Need read/write rights on statedir /var/lib/swtpm-localca for user tss.
swtpm-localca exit with status 256:
An error occurred. Authoring the TPM state failed.
Ending vTPM manufacturing @ Mon 15 Nov 2021 01:38:53 PM UTC

That is ok for Jammy, but we need to think what we want in backports to Focal.
If people used swtpm from a PPA or snap before then the chmod in the postinst
will break running and starting guests.

Changed in libvirt (Ubuntu):
assignee: Utkarsh Gupta (utkarsh) → nobody
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

#1 old state

ubuntu@node-horsea:~$ sudo ls -laFR /var/log/swtpm/libvirt/qemu /run/libvirt/qemu/swtpm /var/lib/libvirt/swtpm
/run/libvirt/qemu/swtpm:
total 4
drwxrwx--- 2 libvirt-qemu tss 80 Nov 15 13:43 ./
drwxr-xr-x 5 root root 180 Nov 15 13:43 ../
-rw-r--r-- 1 tss tss 4 Nov 15 13:43 4-f-tpm-swtpm.pid
srw------- 1 libvirt-qemu kvm 0 Nov 15 13:43 4-f-tpm-swtpm.sock=

/var/lib/libvirt/swtpm:
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwxr-xr-x 8 root root 4096 Nov 15 13:38 ../
drwx--x--x 3 root root 4096 Nov 15 13:43 65113265-34d6-4358-b562-4d7508d6ff17/

/var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17:
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
drwx------ 2 tss tss 4096 Nov 15 13:43 tpm2/

/var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17/tpm2:
total 16
drwx------ 2 tss tss 4096 Nov 15 13:43 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
-rw-r----- 1 tss tss 0 Nov 15 13:43 .lock
-rw------- 1 tss tss 6098 Nov 15 13:43 tpm2-00.permall

/var/log/swtpm/libvirt/qemu:
total 16
drwx-wx--- 2 tss tss 4096 Nov 15 13:38 ./
drwx--x--x 3 root root 4096 Nov 15 13:38 ../
-rw-r--r-- 1 tss tss 4744 Nov 15 13:43 f-tpm-swtpm.log

We see a few things effectively owned by the guest libvirt-qemu user.
And others by tss, mostly the state file and log files.

And the processes are running as tss
1 106 9007 1 20 0 7492 4136 - Ss ? 0:00
/usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/
4-f-tpm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/65113265-
34d6-4358-b562-4d7508d6ff17/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/
qemu/f-tpm-swtpm.log --tpm2 --pid file=/run/libvirt/qemu/swtpm/4-f-tpm-swtpm.pid

$ id tss
uid=106(tss) gid=111(tss) groups=111(tss)
$ id swtpm
uid=116(swtpm) gid=126(swtpm) groups=126(swtpm)

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

#2 upgrade

The Postinst only modified /var/lib/swtpm-localca if it was not yet existing.
So in this case it did not modify it, but again that is only for PPA/Manual users
and on a major upgrade (to 22.04) is ok as a admin task to resolve the former
to the new setup.

Upgrading to the new libvirt will change the user it tries to run swtpm with.

Since I used the default conf content before no prompt happened and the config
is switched:

ubuntu@node-horsea:~$ sudo grep swtpm /etc/libvirt/qemu.conf:
# User for the swtpm TPM Emulator
# Default is 'swtpm' as established by the swtpm-tools package.
# which isn't needed to swtpm.
swtpm_user = "swtpm"
swtpm_group = "swtpm"

Without breakage (this is the upgrade case where /var/lib/swtpm-localca still
is owned by tss:tss) this works still fine. This is due to swtpm-localca being
called by libvirtd upfront and not being related to the later run of swtpm
itself.

Logfile, tpm state and process are owned by swtpm now.

1 116 15361 1 20 0 7492 4084 - Ss ? 0:00
/usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/
5-f-tpm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/65113265-
34d6-4358-b562-4d7508d6ff17/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt/
qemu/f-tpm-swtpm.log --tpm2 --pid file=/run/libvirt/qemu/swtpm/5-f-tpm-swtpm.pid

-rw-r--r-- 1 swtpm swtpm 4744 Nov 15 13:43 f-tpm-swtpm.log
-rw------- 1 swtpm swtpm 6098 Nov 15 13:56 tpm2-00.permall
-rw-r--r-- 1 swtpm swtpm 5 Nov 15 13:56 5-f-tpm-swtpm.pid

The socket (where the guest reaches swtpm) still is libvirt-qemu as intended
srw------- 1 libvirt-qemu kvm 0 Nov 15 13:56 5-f-tpm-swtpm.sock=

But as I said, the local-ca content is tss still
/var/lib/swtpm-localca:
total 56
drwxr-x--- 2 tss root 4096 Nov 15 13:43 ./
drwxr-xr-x 49 root root 4096 Nov 15 13:52 ../
-rwxr-xr-x 1 tss tss 0 Nov 15 13:43 .lock.swtpm-localca*
-rw-r--r-- 1 tss tss 5531 Nov 15 13:43 01.pem
-rw-r--r-- 1 tss tss 1 Nov 15 13:43 certserial
-rw-r--r-- 1 tss tss 48 Nov 15 13:43 index.txt
-rw-r--r-- 1 tss tss 21 Nov 15 13:43 index.txt.attr
-rw-r--r-- 1 tss tss 0 Nov 15 13:43 index.txt.old
-rw-r--r-- 1 tss tss 5531 Nov 15 13:43 issuercert.pem
-rw-r--r-- 1 tss tss 3 Nov 15 13:43 serial
-rw-r--r-- 1 tss tss 3 Nov 15 13:43 serial.old
-rw-r----- 1 tss tss 2459 Nov 15 13:43 signkey.pem
-rw-r--r-- 1 tss tss 1468 Nov 15 13:43 swtpm-localca-rootca-cert.pem
-rw-r----- 1 tss tss 2455 Nov 15 13:43 swtpm-localca-rootca-privkey.pem

Note: purging swtpm-tools leaves /var/lib/swtpm-localca but
dir itself behind, therefore purge+install does not get the state
that a fresh install would. I think that is a bug and filed it at
bug 1950986

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Download full text (6.1 KiB)

#3 Fresh install of the new version

This now has /var/lib/swtpm-localca set to swtpm.

$ sudo ls -laF /var/lib/swtpm-localca
total 8
drwxr-x--- 2 swtpm root 4096 Nov 15 14:05 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../

Starting the guest works and ownership is correct:

$ sudo ls -laFR /var/log/swtpm/libvirt/qemu /run/libvirt/qemu/swtpm /var/lib/libvirt/swtpm /var/lib/swtpm-localca
/run/libvirt/qemu/swtpm:
total 4
drwxrwx--- 2 libvirt-qemu swtpm 80 Nov 15 14:06 ./
drwxr-xr-x 5 root root 180 Nov 15 14:06 ../
-rw-r--r-- 1 swtpm swtpm 5 Nov 15 14:06 6-f-tpm-swtpm.pid
srw------- 1 libvirt-qemu kvm 0 Nov 15 14:06 6-f-tpm-swtpm.sock=

/var/lib/libvirt/swtpm:
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwxr-xr-x 8 root root 4096 Nov 15 13:38 ../
drwx--x--x 3 root root 4096 Nov 15 13:43 65113265-34d6-4358-b562-4d7508d6ff17/

/var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17:
total 12
drwx--x--x 3 root root 4096 Nov 15 13:43 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
drwx------ 2 swtpm swtpm 4096 Nov 15 14:06 tpm2/

/var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17/tpm2:
total 16
drwx------ 2 swtpm swtpm 4096 Nov 15 14:06 ./
drwx--x--x 3 root root 4096 Nov 15 13:43 ../
-rw-r----- 1 swtpm swtpm 0 Nov 15 14:06 .lock
-rw------- 1 swtpm swtpm 6098 Nov 15 14:06 tpm2-00.permall

/var/lib/swtpm-localca:
total 8
drwxr-x--- 2 swtpm root 4096 Nov 15 14:05 ./
drwxr-xr-x 49 root root 4096 Nov 15 14:05 ../

/var/log/swtpm/libvirt/qemu:
total 16
drwx-wx--- 2 swtpm swtpm 4096 Nov 15 13:38 ./
drwx--x--x 3 root root 4096 Nov 15 13:38 ../
-rw-r--r-- 1 swtpm swtpm 4744 Nov 15 13:43 f-tpm-swtpm.log

Process as well

1 116 16253 1 20 0 7492 3776 - Ss ? 0:00
/usr/bin/swtpm socket --daemon --ctrl type=unixio,path=/run/libvirt/qemu/swtpm/
6-f-tpm-swtpm.sock,mode=0600 --tpmstate dir=/var/lib/libvirt/swtpm/65113265-
34d6-4358-b562-4d7508d6ff17/tpm2,mode=0600 --log file=/var/log/swtpm/libvirt
/qemu/f-tpm-swtpm.log --tpm2 --pid file=/run/libvirt/qemu/swtpm/6-f-tpm-swtpm.pid

What slightly puzzles me is the empty /var/lib/swtpm-localca dir

I created a new guest to see if that behaves different than the one used before.
Indeed it behaves differently.

swtpm log on guest that existed before:

Starting vTPM manufacturing as tss:tss @ Mon 15 Nov 2021 01:38:53 PM UTC
Successfully created RSA 2048 EK with handle 0x81010001.
  Invoking /usr/lib/x86_64-linux-gnu/swtpm/swtpm-localca --type ek --ek df06f941e4c58e2c043407c1eb2a5afa6825ee93362ebe33e8ada87986bd04bb356ee64d02625f9cb234bf13afbd4d5e93456ad24dccd1b3083b063d4098573045dd1f8c73ee1ca8860f2f5f211ccd6336774388202099dd6117e38ebe162a34e7af024f6eac15c9683979ef4f4fbe5bda39284d209bfe32897ad87df062382e3ce6a070cfbc325223d6e12f366bb115fbadf78e66790d6e04f5d8f27f6e8ca431bb779fe8b67e6707ceb36de8540838f2acab6535fcf1739e7b51f22d4d774c17c1e56d86d64e52319d5303ab7c8e47303c359858ace7b282d6ff696930a595db20202884417fe19b00d2272966979bedc7c36e678fbaf26be84fdfa7059ddf --dir /var/lib/libvirt/swtpm/65113265-34d6-4358-b562-4d7508d6ff17/tpm2 --logfile /var/log/swtpm/libvirt/qemu/f-tpm-swtpm.log --vmid f-tpm:65113265-34d6-4358-b562-4d7508d6ff17 --tp...

Read more...

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

TL;DR
- the libvirt config change of this upload works fine
- actually since swtpm-tools switched the default this upload is required to
  work without changing the .conf files
- for 22.04 this LGTM and can be uploaded after a MR review
- for SRUs it might need more considerations.
  On one hand if we consider the transition from PPA/snap swtpm we'd not want to
  change the user/group this runs with which implies swtpm backports should
  stick to tss:tss.
  OTOH none of these former things are in the archive, we have no guarantees
  about their behavior anyway, so we can argue that we come from "nothing" to
  "swtpm:swtpm".
  But all that is for SRU of swtpm and then potentially this bug here and comes
  later

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

FYI - uploaded to Jammy

Changed in libvirt (Ubuntu):
assignee: nobody → Christian Ehrhardt  (paelzer)
tags: removed: server-next
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libvirt - 7.6.0-0ubuntu3

---------------
libvirt (7.6.0-0ubuntu3) jammy; urgency=medium

  * d/libvirt-daemon-system.postinst: create user/group swtpm if not present
    due to swtpm-tools (LP: #1951975)

 -- Christian Ehrhardt <email address hidden> Wed, 24 Nov 2021 07:50:53 +0100

Changed in libvirt (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.