On 11/5/24 1:12 PM, Peter Maydell wrote:
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
If you are root you can change things. I have shown the options using
aa-complain and aa-disable that you can revert once the test has
finished: sudo aa-enforce /usr/bin/swtpm
You could also copy swtpm into a user-owned directory but you will have
to adapt the user's PATH. That's an easy option.
The most compatible option is the 3rd option since I would expect that
we will have this rule in a future version of the usr.bin.swtpm Ubuntu
profile provided by the swtpm package:
echo "include <abstractions/user-tmp>" >>
/etc/apparmor.d/local/usr.bin.swtpm
apparmor_parser -r /etc/apparmor.d/usr.bin.swtpm
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).
I am not aware of how user/non-root-started programs can be generally
made exempt from AppArmor.
There may still be a security boundary if a user runs QEMU and swtpm was
able to manipulate (with malicious input) the user's files in some
undesirable way or copy the user's data elsewhere. In this case it may
be desirable for the user that the profile be applied and the PATH he is
using points to the standard swtpm.
thanks
-- PMM
