Hi On Tue, Sep 17, 2019 at 12:12 PM Dr. David Alan Gilbert <dgilb...@redhat.com> wrote: > > * Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > > Hi > > > > On Mon, Sep 16, 2019 at 5:15 PM Dr. David Alan Gilbert > > <dgilb...@redhat.com> wrote: > > > > > > * Marc-André Lureau (marcandre.lur...@gmail.com) wrote: > > > > Hi > > > > > > > > On Mon, Sep 16, 2019 at 2:02 PM Dr. David Alan Gilbert > > > > <dgilb...@redhat.com> wrote: > > > > > > > > > > (Copying in Stefan since he was looking at DBus for virtiofs) > > > > > > > > > > * Marc-André Lureau (marcandre.lur...@redhat.com) wrote: > > > > > > Signed-off-by: Marc-André Lureau <marcandre.lur...@redhat.com> > > <snip> > > > > > Do you have a specific question we can answer or guide for qemu? Is > > > > there something we have to document or implement? > > > > > > > > Since qemu is not managing the extra processes or applying policies, I > > > > don't know what else could be done. From qemu pov, it can rely on > > > > management layer to trust the bus and the helpers, similar to trusting > > > > the system in general. > > > > > > Well pretty much the same questions I asked in the discussion on v2; > > > what is the supported configuration to ensure that one helper that's > > > been compromised can't attack the others and qemu? > > > > I thought I gave the answer to that question above. What is missing? I > > don't think one can generalize it here, it will be a case by case for > > each helper, how they interact with each other and qemu. > > I think we need an example of how to lock it down; i.e. to allow a > helper to provide migration data but not to be able to speak to other > helpers. >
That's the example policy I gave for dbus-dameon. Only qemu user can talk to Helper1 (for ex, a helper migration interface). Only qemu-helper user can claim Helper1. You could have additionally other ways: selinux policy, p2p helpers SCM credentials checks, or other methods. -- Marc-André Lureau
