[PATCH] NEWS: note new passt feature & bugfix for 9.1.0 release

[Stefano Brivio]

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