Re: [PULL 10/17] tests/functional: Convert most Aspeed machine tests

[Stefan Berger <stefanb@linux.ibm.com>]

On 11/5/24 1:12 PM, Peter Maydell wrote:
> On Tue, 5 Nov 2024 at 18:02, Stefan Berger <stefanb@linux.ibm.com> wrote:
>>
>>
>>
>> On 11/5/24 12:13 PM, Peter Maydell wrote:
>>> On Tue, 5 Nov 2024 at 17:02, Stefan Berger <stefanb@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
>