Re: GUPnP and Zones

[Ludovic Ferrandis <ludovic ferrandis linux intel com>]

Hi Mark,

On 22/04/2013 13:53, Mark Ryan wrote:
> 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
>
> _______________________________________________
> gupnp-list mailing list
> gupnp-list gnome org
> https://mail.gnome.org/mailman/listinfo/gupnp-list

About Network Zone, I didn't read doc for now, but I hope we can work 
with 'Network Zone predefined type' and not only with the Zone name.
It will be a nightmare to manage with localization. But I think this is 
our least problem.

The main goal of Network Zone, it to manage the firewall rules 
differently, depending of the 'Zone' selected.
In case we are working with a network manager that support Network Zone, 
we don't have anything to do. I explain.

Everything could be done just by changing the firewall rules. Ex:

First case: 'Trusted' networks. All ports open, incoming & outgoing. 
Rygel could publish and dLeyna can discover and use DMS/DMR.

Second case: 'Public' networks. SSDP port closed (among others) and all 
incoming ports blocked. dLeyna won't be able to discover any DMS/DMR and 
Rygel will not be seen outside the firewall.

Third case: 'Home' network. All outgoing port open, all incoming (except 
SSDP) port blocked. dLeyna could discover DMS/DMR, and will be able to 
establish communication with DMS/DMR.

Fourth case: 'Work' network. All ports < 10000 open incoming & outgoing. 
SSDP will works, but if Rygel is using dynamic port attribution and run 
with a port > 10000, we will be able to see it, but not to communicate 
with it.

IMHO, Network Zone is a nice to have information, but we don't have 
anything to do. We should let the firewall do it's job.
At least, we need to work with the Network Manager team so they can 
manage UPnP/DLNA rules in the firewall for the various predefined Zone.

The only case we should manage Network Zone, is for optimization, to 
prevent the DMS for ex to broadcast SSDP packet that will be blocked by 
the firewall.
But I'm not sure it worth the effort. We are going to add code and 
potentially bugs, for a minimal gain.


This is off topic I think, but for system that don't have Network Zone, 
a new component could simulate it, in the simplest way, by associating a 
Zone to a new interface. But that means a new daemon, UX, Storage... Not 
sure it worth the effort either.


There is also another way to provide some protection/privacy, it's by 
using the Network Type information, eg, Ethernet, Wifi, 2/3/4G, etc...
Maybe you don't want to run a DMC on a 2G network, but why not on a 4G 
network (if you have a unlimited data plan, you have sufficient bandwidth)
You want your DMS to run only on Ethernet network type.
...
This information could easily be made public.


Ludo

--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation