GUPnP and Zones

[Mark Ryan <mark d ryan linux intel com>]

Hi All,

I've been thinking about security a bit lately, from the point of view 
of the client and not the server.

Obviously, we don't want to run a DMS or a DMR on any Wifi Network we 
connect to.  However, it occurs to me that we don't want to run the 
control points on public networks either as doing so might introduce an 
attack vector, i.e., someone could create a fake server that forces the 
clients to  download and parse dodgy XML files. They could also send 
dubious notify messages to the port opened up by the control point to 
receive notifications.  I could be being over paranoid here, but it 
seems to me that it's not safe to run any UPnP client on a public 
network.  It's also a waste of resources to do so.

Now Rygel already partially addresses this issue.  It allows the user to 
restrict its services to a list of network address or SSIDs.  As far as 
I know, none of the clients, e.g., gupnp-av, dLeyna, allow users to 
restrict their use in this way.    In addition, by default, Rygel's 
trusted network list is blank which means that its services are 
available on all connected network interfaces, unless the user 
specifically changes this behaviour.

A solution to this problem discussed in the past was to take advantage 
of zone support in the various context managers.  However, at the time 
this support was only being discussed and had not been actually 
implemented.  The good news now is that it seems that Network Manager, 
in conjunction with firewalld, now support the concept of zones. ( 
http://lwn.net/Articles/484506/ ).

The question is, how can we take advantage of zone support in 
GUPnP/Rygel/dLeyna.

One suggestion discussed on IRC was to do all the interface filtering in 
GUPnP rather than in Rygel or the control points.  By default, GUPnP 
would only expose contexts that belong to a whitelist of trusted zones, 
e.g., "'trusted', 'home', 'work', and 'internal'", assuming zones are 
supported by the underlying network manager.  However, this behaviour 
could be overridden by clients by calling a new GUPnP API.  GUPnP 
clients could restrict the network interfaces used by specifying a 
combination of zones, ip address or SSIDs.  To quote from IRC

phako> so you can say eth0, zone "Home" and SSID MyCompanysWifi

Perhaps the default list of zones/interfaces could be overridden by a 
compile time option to give distributions control over the default 
behaviour.  Also, I think these strings, e.g., "trusted", might come 
from firewalld and if you were using a different firewall you might want 
to specify a different set of default zones.

So what do people think about this?  Does this seem like a sensible plan?

Regards,

Mark