Re: [Qemu-devel] [PATCH 0/7] Provide support for the software TPM emulator

[Daniel P. Berrange]

On Mon, Apr 03, 2017 at 05:18:37PM +0000, Marc-André Lureau wrote:
> Hi
> 
> On Mon, Apr 3, 2017 at 7:08 PM Daniel P. Berrange <address@hidden>
> wrote:
> 
> > On Fri, Mar 31, 2017 at 04:10:09PM +0300, Amarnath Valluri wrote:
> > > Briefly, Theses set of patches introduces:
> > >  - new TPM backend driver to support software TPM emulators(swtpm(1)).
> > >  - and few supported fixes/enhancements/cleanup to existing tpm backend
> > code.
> > >
> > > The similar idea was initiated earliar(2) by Stefan Berger(CCed) with
> > slightly
> > > different approach, using CUSE. As swtpm has excellent support for unix
> > domain
> > > sockets, hence this implementation uses unix domain sockets to
> > communicate with
> > > swtpm.
> > >
> > > When Qemu is configured with 'emulator' tpm backend, it spawns 'swtpm'
> > and
> > > communicates its via Unix domain sockets.
> >
> > I'm not convinced that having QEMU spawning swtpm itself is a desirable
> > approach, as it means QEMU needs to have all the privileges that swtpm
> > will need, so that swtpm can inherit them. At the very least I think we
> > need to have a way to disable this spawning, so it can connect to a
> > pre-existing swtpm process that's been spawned ahead of time. This will
> > let us have stricter privilege separation.
> >
> 
> Could the security contexts be given as arguments to qemu for the
> subprocesses? The reason to have qemu spawn its own subprocess is that it
> would leave more flexibility on how and when to do it, or even to use
> multiple subprcesses if some day that makes sense. If there is no reason to
> make this interface public or shared by various other processes, I would
> rather see it as internal to qemu rather than managed by other tools. It
> also makes command line & testing easier.

If QEMU is responsible for spawning it, then swtpm would have to run as the
same user/group as QEMU, as we do not want QEMU to have ability to invoke
programs with setuid. This means any state files / config / devices that
swtpm has to access would also be accessible by QEMU directly (assuming just
DAC controls, no MAC like SELinux). It also means that swtpm would be able
to access QEMU resources - so a bug in swtpm would allow swtpm to compromise
the guest disk image and other resources QEMU access.

If by contrast, libvirtd is responsible for spawning it, or an even a higher
level mgmt app like OpenStack/oVirt, then swtpm can be run with completely
isolated user / group privileges. The only resource that QEMU needs access
to is the UNIX domain socket, and swtpm doesn't need to access anything
belonging to QEMU. This will give us much stronger security separation
between swtpm & QEMU.  It will also allow us to write a more useful seccomp
policy that entirey blocks exec() from QEMU, further mitigating damage from
potential QEMU exploits. 

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|