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

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

On 11/5/24 2:54 PM, Peter Maydell wrote:
> On Tue, 5 Nov 2024 at 18:36, Stefan Berger <stefanb@linux.ibm.com> wrote:
>> 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:
>>> 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.
> 
> But our test makefiles could equally well just run "cp" !
> swtpm has no privilege here that we do not already have.
> 
> Anyway, the thing here is that we run swtpm like this:
> 
>   swtpm socket -d  --tpm2 --tpmstate dir=/path/to/somewhere --ctrl
> type=unixio,path=/path/to/socket
> 
> where we use command line arguments to tell it where to
> put the tpmstate and the socket.
> 
> Either:
>   (1) there are places where it's not valid for us to tell swtpm to
> put the tpmstate or to put the control socket
>   (2) it's valid to put those anywhere we like
> 
> If (1), then swtpm should give a clear error message that we've
> given it an invalid argument (and its manpage should say what
> the restrictions are)

There are no restrictions on the swtpm level when it comes to paths.

> If (2), then apparmor should not be rejecting this usage

AppArmor file restrictions are all path based. We have support for home 
directory and /tmp, but were missing /var/tmp. So, please.

 > > One of swtpm or apparmor must be wrong here and I think it should
> be fixed. In particular, having the failure mode be "something

As stated, we were going to fix the AppArmor path in the swtpm Ubuntu 
package.

> goes wrong after swtpm has successfully started and only once
> it gets sent the TPM_INIT command, and the information about it
> only winds up in the syslog" is pretty awkward -- it would
> be much nicer if it failed fast, as soon as you ran it, and
> printed the error to stderr.
> 
> In the interim, since we'd like to be able to run the test suite
> on Ubuntu, it sounds like we can work around this by putting
> the tpmstate and socket in either /tmp/ or somewhere under
> the user's home directory.

Right, I gave several options.

> 
> thanks
> -- PMM
>