[Bug 1992377] Re: Update apparmor profile to match upstream

[Lena Voytek]

** Summary changed:

- Apparmor denies writing to swtpm lock file in user's home directory
+ Update apparmor profile to match upstream

** Description changed:

+ [Impact]
+ 
+ In its current state, swtpm's apparmor profile has a few restrictions that block common use cases for the software. This includes:
+  - Use of vtpm proxy
+  - Using one's home folder to manage TPM states
+  - Some qemu and libvirt interactions in the tmp directory
+ 
+ Cleaning up these restrictions allows users to run swtpm in these common
+ configurations without messing with local apparmor profiles.
+ 
+ To fix these cases, the swtpm apparmor profile has been updated to match
+ upstream. During the process of bringing the Ubuntu version of the
+ profile upstream, these issues were found and fixed accordingly. More
+ info on these changes can be found here:
+ https://github.com/stefanberger/swtpm/pull/691
+ 
+ [Test Plan]
+ 
+ The fix can be tested by running swtpm in these situations. The
+ following can be used to test using the home folder to manage TPM states
+ using a Windows 11 ISO:
+ 
+ $ sudo apt install swtpm qemu-kvm
+ $ qemu-img create -f qcow2 win11.img 64G
+ $ mkdir ~/tpmstatedir
+ $ swtpm socket --tpm2 --ctrl type=unixio,path=/tmp/swtpm-sock --tpmstate dir=~/tpmstatedir
+ $ sudo qemu-system-x86_64 -hda win11.img -boot d -m 4096 -enable-kvm -chardev socket,id=chrtpm,path=/tmp/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -cdrom Win11.iso
+ 
+ [Where problems could occur]
+ 
+ This change only decreases apparmor restrictions, so users will not be
+ blocked by any new rules. However, with less restrictions, swtpm is
+ provided with more attack vectors if it were to be compromised. swtpm
+ will no longer be blocked in accessing tmp files that are not its own,
+ and will have additional abilities to manipulate file permissions. If
+ swtpm acted maliciously, it could access and mess with temporary files
+ belonging to other programs.
+ 
+ [Other Info]
+  
+ This bug has been fixed in kinetic and beyond in version 0.6.3-0ubuntu4.
+ 
+ [Original Description]
+ 
  When a user uses a tpm state directory for swtpm located somewhere in
  their home directory, apparmor will deny the creation of a lock file
  when a qemu vm boots, showing a message such as:
  
  audit: type=1400 audit(1665412130.135:170): apparmor="DENIED"
  operation="mknod" profile="swtpm" name="/home/.../tpmstatedir/.lock"
  pid=5218 comm="swtpm" requested_mask="c" denied_mask="c" fsuid=1000
  ouid=1000
  
  This is due to a missing line in the apparmor profile that has been
  added upstream:
  
  owner @{HOME}/** rwk,
  
- 
  To test (using a Windows 11 iso):
  
  $ sudo apt install swtpm qemu-kvm
  $ qemu-img create -f qcow2 win11.img 64G
  $ mkdir ~/tpmstatedir
  $ swtpm socket --tpm2 --ctrl type=unixio,path=/tmp/swtpm-sock --tpmstate dir=~/tpmstatedir
  $ sudo qemu-system-x86_64 -hda win11.img -boot d -m 4096 -enable-kvm -chardev socket,id=chrtpm,path=/tmp/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -cdrom Win11.iso

** Changed in: swtpm (Ubuntu Jammy)
       Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to swtpm in Ubuntu.
https://bugs.launchpad.net/bugs/1992377

Title:
  Update apparmor profile to match upstream

Status in swtpm:
  Unknown
Status in swtpm package in Ubuntu:
  Fix Released
Status in swtpm source package in Jammy:
  In Progress
Status in swtpm source package in Kinetic:
  Fix Released

Bug description:
  [Impact]

  In its current state, swtpm's apparmor profile has a few restrictions that block common use cases for the software. This includes:
   - Use of vtpm proxy
   - Using one's home folder to manage TPM states
   - Some qemu and libvirt interactions in the tmp directory

  Cleaning up these restrictions allows users to run swtpm in these
  common configurations without messing with local apparmor profiles.

  To fix these cases, the swtpm apparmor profile has been updated to
  match upstream. During the process of bringing the Ubuntu version of
  the profile upstream, these issues were found and fixed accordingly.
  More info on these changes can be found here:
  https://github.com/stefanberger/swtpm/pull/691

  [Test Plan]

  The fix can be tested by running swtpm in these situations. The
  following can be used to test using the home folder to manage TPM
  states using a Windows 11 ISO:

  $ sudo apt install swtpm qemu-kvm
  $ qemu-img create -f qcow2 win11.img 64G
  $ mkdir ~/tpmstatedir
  $ swtpm socket --tpm2 --ctrl type=unixio,path=/tmp/swtpm-sock --tpmstate dir=~/tpmstatedir
  $ sudo qemu-system-x86_64 -hda win11.img -boot d -m 4096 -enable-kvm -chardev socket,id=chrtpm,path=/tmp/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -cdrom Win11.iso

  [Where problems could occur]

  This change only decreases apparmor restrictions, so users will not be
  blocked by any new rules. However, with less restrictions, swtpm is
  provided with more attack vectors if it were to be compromised. swtpm
  will no longer be blocked in accessing tmp files that are not its own,
  and will have additional abilities to manipulate file permissions. If
  swtpm acted maliciously, it could access and mess with temporary files
  belonging to other programs.

  [Other Info]
   
  This bug has been fixed in kinetic and beyond in version 0.6.3-0ubuntu4.

  [Original Description]

  When a user uses a tpm state directory for swtpm located somewhere in
  their home directory, apparmor will deny the creation of a lock file
  when a qemu vm boots, showing a message such as:

  audit: type=1400 audit(1665412130.135:170): apparmor="DENIED"
  operation="mknod" profile="swtpm" name="/home/.../tpmstatedir/.lock"
  pid=5218 comm="swtpm" requested_mask="c" denied_mask="c" fsuid=1000
  ouid=1000

  This is due to a missing line in the apparmor profile that has been
  added upstream:

  owner @{HOME}/** rwk,

  To test (using a Windows 11 iso):

  $ sudo apt install swtpm qemu-kvm
  $ qemu-img create -f qcow2 win11.img 64G
  $ mkdir ~/tpmstatedir
  $ swtpm socket --tpm2 --ctrl type=unixio,path=/tmp/swtpm-sock --tpmstate dir=~/tpmstatedir
  $ sudo qemu-system-x86_64 -hda win11.img -boot d -m 4096 -enable-kvm -chardev socket,id=chrtpm,path=/tmp/swtpm-sock -tpmdev emulator,id=tpm0,chardev=chrtpm -device tpm-tis,tpmdev=tpm0 -cdrom Win11.iso

To manage notifications about this bug go to:
https://bugs.launchpad.net/swtpm/+bug/1992377/+subscriptions