qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] [PATCH 00/17] Framework for securely passing secrets to QEMU
Date: Mon, 19 Oct 2015 18:46:07 +0100
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Oct 19, 2015 at 06:13:24PM +0100, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrange (address@hidden) wrote:
> 
> <snip>
> 
> > It is obvious there there is a wide variety of functionality
> > in QEMU that needs access to "secrets". This need will only
> > grow over time. We need to stop having everyone invent their
> > own dangerous wheels and provide a standard mechanism for
> > securely passing secrets to QEMU.
> 
> Agreed.
> 
> > 
> > To this end, this series introduces a QCryptoSecret object
> > class with short name "secret". All the places which needs
> > passwords/keys are then converted to get their via this
> > API, except VNC/SPICE which are a future exercise.
> > 
> > Example usage for creating secrets...
> > 
> > Direct password, insecure, for ad-hoc developer testing only
> > 
> >   $QEMU -object secret,id=sec0,data=letmein
> > 
> > Indirect password via a file, good for production
> > 
> >   echo -n "letmein" > mypasswd.txt
> >   $QEMU -object secret,id=sec0,file=mypasswd.txt
> > 
> > The file based approach supports file descriptor passing,
> > so mgmt apps can use that to dynamically add passwords to
> > running QEMU.
> 
> Would it make any sense to support the Linux kernel key system?
> That seems to have a way of passing keys between a limited
> set of processes and protecting them using SELinux and the like.
> 
> (I can also imagine that people might want to feed it with keys
> from a TPM or other hardware security device, but fortunately
> I can't remember enough about TPMs to remember how getting
> keys worked).

I don't really know enough about the Linux key system to answer
that very well.

It does of course have the obvious downside that it is Linux
specific, so it would have to be an optional further extension
to the basic portable framework I've implemented so. Given that
I'll say this is an area someone else can explore in the future
if they have desire todo so :-)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]