On 11/5/24 4:34 PM, Peter Maydell wrote:
On Tue, 5 Nov 2024 at 20:12, Stefan Berger <stef...@linux.ibm.com> wrote:
On 11/5/24 2:54 PM, Peter Maydell wrote:
On Tue, 5 Nov 2024 at 18:36, Stefan Berger <stef...@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
