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

[Stefan Berger]

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