[Spice-devel] Questions on security.

[Alexander Larsson]

On Mon, 2010-05-03 at 16:56 -0700, Robert Relyea wrote:
> Hi all,
> 
> I've been asked to look at the security of the spice protocol. I've
> looked at the project a bit already and have a few potential things to
> talk about, but I wanted to understand some of the underlying
> assumptions before I get too far into it.
> 
Sorry for the late answer. We were a bit busy with team meetings and
whatnot.

> First, I want to confirm that the protocol itself is not meant to be
> 'secure' (resistant to active and passive attacks)  unless secured by
> some higher level channel protocol (like SSL). NOTE: this is not
> unusual, most internet protocols are not secured unless transported
> through a trusted pipe like SSL. -- It's usually considered better to
> use an existing security protocol for a transport than to create a
> brand new secure protocol from scratch. The chances of getting
> something wrong is pretty high even for security protocol experts.
> 
It depends on what you mean. Spice is a somewhat complex protocol that
uses multiple tcp connections per client connection, so there is no
simple layering of "spice over ssl". However, spice itself does
(optionally) support encrypting some or all of the channels using ssl.
This all depends on how you launch/configure it.

> If it is meant to be secure, what types of attacks is it supposed to
> prevent without a secure channel? Is it, for instance, meant to have
> strong authentication?
> 
> There will probably be some more questions depending on the answers to
> these. I couldn't find any security deployment guide (not surprising
> at this stage), which would answer these questions.

I don't think we ever sat down and discussed this, but I think these are
the kinds of things we expect spice to be robust against:

* Software running inside the guest trying to attack the host that runs
the guest os instance

* When the client connects to the server there is some form of
authentication so that not anyone can connect to a "private" guest
instance. This is atm done via password set at the server side which the
client must supply (i'm not sure how exactly this is implemented, i hope
its not passing the password over the net)

* When a client is active we (optionally) don't want anyone to be able
listen to the data, or hijack the connection. This is done by allowing
channels to be secured via ssl.

* When we're migrating the guest os to another server we automatically
have the client connect to the new server, and we need to ensure that
the client doesn't connect to some rouge server but really to the
"same" (migrated) guest.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's an unconventional moralistic househusband from a doomed world. She's a 
transdimensional kleptomaniac research scientist who dreams of becoming Elvis. 
They fight crime!