On Tue, 28 Feb 2023 13:29:18 -0800 Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, Feb 28, 2023 at 07:53:09PM +0100, Stefano Brivio wrote:
On Tue, 28 Feb 2023 10:06:18 -0800 Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, Feb 28, 2023 at 09:49:26AM -0500, Laine Stump wrote:
+ (NB: it is still necessary to disable SELinux to start passt.)
This is also true for AppArmor, so I would mention both.
Not in general -- thankfully, no pseudorandom label is forced by libvirt 9.1.0 with AppArmor (because there are no labels), and libvirtd simply runs passt unconfined (scrubbing the environment):
$ grep "/usr/bin" src/security/apparmor/usr.sbin.libvirtd.in /usr/bin/* PUx,
Then yes, with any recent version of Debian and openSUSE packages of passt, passt won't be able to create the socket or its PID file in the path libvirt asks for, because of the profile shipping with passt itself.
From the user's point of view, what is the difference between passt not being able to start, or starting successfully but quitting immediately afterwards because it can't create some files? I don't think there's one. In both cases, you're going to see an error.
Yes yes, that's what I meant, there's no difference -- *but "just" with Debian or openSUSE packages*, because they ship AppArmor profiles for passt. If you don't use packages, or, let's say, the Arch Linux package (https://aur.archlinux.org/packages/passt-git), this is not an issue, no matter the LSM.
Note that I'm *not* recommending to do this, just like I'm not recommending to disable SELinux, and I don't think it's a good idea to suggest in release notes that users do this, either.
This is a limitation of the current implementation of passt support in libvirt. We're actively working on removing it, but in the meantime it should be documented somewhere. Are the release notes the best place for that? Unclear. I don't think it's a particularly bad one.
Me neither -- I actually suggested that if libvirt really needs to ship a feature in this state, at least this should be added to the notes, so that users don't think they're the ones doing something wrong, if things don't work.
Anyone reading "you need to disable SELinux to use this feature" will surely infer that they shouldn't put it into production yet :)
I don't know, I guess you're most likely right, but I still see the possible interpretation of a recommendation. At least as an argument in the evaluation of vulnerability metrics. I'm really fine with either Laine's version or your version, for what it's worth. -- Stefano