On Tue, 5 Nov 2024 at 18:36, Stefan Berger <stef...@linux.ibm.com> wrote: > On 11/5/24 1:12 PM, Peter Maydell wrote: > > On Tue, 5 Nov 2024 at 18:02, Stefan Berger <stef...@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) If (2), then apparmor should not be rejecting this usage One of swtpm or apparmor must be wrong here and I think it should be fixed. In particular, having the failure mode be "something 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. thanks -- PMM
