On Tue, 5 Nov 2024 at 18:02, Stefan Berger <stef...@linux.ibm.com> wrote: > > > > On 11/5/24 12:13 PM, Peter Maydell wrote: > > On Tue, 5 Nov 2024 at 17:02, Stefan Berger <stef...@linux.ibm.com> wrote: > >> On 11/5/24 11:14 AM, Peter Maydell wrote: > >>> Q1: why is apparmor forbidding swtpm from doing something that > >>> it needs to do to work? > >> > >> What distro and version is this? > >> > >> The profile may be too strict and not reflecting all the paths needed > >> for running the test cases. Ubuntu for example would have to update > >> their profile in such a case. > > > > This is Ubuntu 22.04 "jammy" (with swtpm 0.6.3-0ubuntu3.3). > > > >>> Q2: is there a way to run swtpm such that it is not > >>> confined by apparmor, for purposes of running it in a test case? > >> > >> Try either one: > >> - sudo aa-complain /usr/bin/swtpm > >> - sudo aa-disable /usr/bin/swtpm > > > > We don't have root access from QEMU's 'make check', > > though (and shouldn't be globally disabling apparmor > > even if we could). I had in mind more a way that an > > individual user can say "run this swtpm process but don't > > apply the apparmor profile to it". > > So the problem is that the avocado tests are using /var/tmp but we only > have AppArmor rules for /tmp/
The file AppArmor gives the error for is not in /var/tmp: it's in a local directory inside QEMU's build dir: Nov 5 16:01:14 e104462 kernel: [946406.489088] audit: type=1400 audit(1730822474.384:446): apparmor="DENIED" operation="mknod" profile="swtpm" name="/mnt/nvmedisk/linaro/qemu-from-laptop/qemu/build/tests/functional/arm/test_arm_aspeed.AST2x00Machine.test_arm_ast2600_evb_buildroot_tpm/qemu-machine-hhuvwytc/.lock" pid=2820156 comm="swtpm" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000 > The following solutions should work: > - do not install swtpm at all > - sudo cp /usr/bin/swtpm /usr/local/bin/swtpm > - as root: echo "include <abstractions/user-tmp>" >> > /etc/apparmor.d/local/usr.bin.swtpm && apparmor_parser -r > /etc/apparmor.d/usr.bin.swtpm Is there no way to just have apparmor not apply at all here? I can see why you might want it to apply for the case of "I'm using it as part of a sandboxed VM setup", but in this scenario I am a local user running this binary which is not setuid root and it is accessing a file in a directory which my user owns and has permissions for. This should not be being rejected: there is no security boundary involved and swtpm is not doing anything that I could not directly do myself anyway (as you can tell from the fact that copying the swtpm binary to a different location and running it works). thanks -- PMM
