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

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

On 11/5/24 4:34 PM, Peter Maydell wrote:
> On Tue, 5 Nov 2024 at 20:12, Stefan Berger <stefanb@linux.ibm.com> wrote:
>> 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:
>>> 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.
> 
> But AIUI the solution you've proposed is to add the user
> temp directory -- abstractions/user-tmp looks like it
> adds permissions for $HOME/tmp, /var/tmp and /tmp/. None
> of those will fix the failure we ran into, because we're not
> using any of those tmp directories. We use a directory
> that's a subdirectory of wherever the user put the build
> directory, which can be anywhere the user has permissions for.

Yes, you are right. The same test failed for me locally due to the usage 
of /var/tmp/ path but that's not what was originally reported.

I am not aware that user-started programs can have an exception from 
having their profiles applied, nor do I know whether rules exist that 
allow a user to circumvent any rule. So my guess is we need rules like 
either one of the following:

owner /mnt/** rwkl

or worse:

owner /** rwkl

I don't see another choice than adding one of these rules, maybe even 
the 2nd. Lena?

> 
> That's why I'm confused -- as far as I can see the only
> way to make swtpm work the way its documentation says it
> should work is to for apparmor to permit anything
> (or at least to permit anything that matches the file paths
> the user handed swtmp, if it can do that).

and from what I know we need explicit rules for allowing paths.

> 
> Or if you want to say "this has to be in one of these
> handful of authorised /tmp/ directories", then it should
> say that in the manpage and check that at init time, not fail
> near-silently much later. At the moment the docs and the
> distro-integration of swtmp disagree, and the effect for
> somebody trying to use it is very confusing.

We haven't run into this type of a problem with paths in a while. The 
applications return 'permission denied' but to find the exact reason 
(LSM) for it one may have to dig into the audit log.

> 
> thanks
> -- PMM