On Tue, 28 Feb 2023 13:29:18 -0800 Andrea Bolognani <abologna@xxxxxxxxxx> 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@xxxxxxxxxx> 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
