GNOME.org
 

Re: GUPnP and Zones

On 26/04/2013 12:07, Mark Ryan wrote:


Hi Ludo,



I must said I'm a little confused about your proposals and about the
direction which takes this discussion.



Sorry about the confusion.  Let me try to summarise the proposals again.

Rygel currently has a mechanism ( a setting in its configuration file )
that allows users to specify the networks on which Rygel publishes
media.  Currently, users can identify networks by specifying an IP
address, a network name or an SSID for wireless networks.  So the
proposal is to

1. Move this feature, which works by filtering contexts, into GUPnP so
that it can be used by all GUPnP clients.  A new GUPnP API would be
added to allow users to specify the networks we are safe to use.



I agree on this as we need something now.


2. Expand this feature so that it can take advantage of zone information
where available.  So this would mean that users could identify safe
networks by IP addresses, SSIDs and zones.



I disagree on this. See below.


Originally, I was proposing introducing a default value for the filter
in GUPnP but Jussi has convinced me that this would not be a good idea
as it would change the behaviour of existing applications.
But we can return Network Zone & Network Type information without breaking the compatibility. It's just new properties in the GUPnP connection manager. For system without Zone support (100% until now), I think Network Type is an important piece of information to manage the rules as you described. 



So, are we talking about managing 'white list', or real support of zones
provided by the Network Manager?

If the goal is to support the Network Manager zones new feature, we
should work with the Network Manager team to ensure DLNA rules are
correctly managed in the various zones.

But we have nothing to do in GUPnP/Rygel/dLeyna as it's NM that will
allow or deny networks.

If your proposal of 'white list' is in addition to Network Zone, then
this is a lame solution, as your solution will only works on networks
already granted by NM.

You won't be able to enable a network, even if you add it in the white
list, if NM has already blocked it.
We will only be able to block a network previously granted by NM.



Your concern about adding zone support to a whitelist in GUPnP seems to
be that the setting might be redundant as it will be overridden by any
rules in the firewall.  This is of course true in theory but I wonder if
it will be in practice.  If we take Ubuntu as an example, AFAIK, the
default Ubuntu firewall on 12.10 doesn't block anything.
Yes, because until now, there is no Zone support in Ubuntu or in NM. It belongs to the user to activate and to configure the firewall. Almost nobody is doing it. 
And in this case, you have to provide the rules yourself.
But that's the purpose of Network Zone feature: to configure the firewall for you, and to change the rules according to the zone selected. 
So if some Zones have UPnP specific rules, we will have to deal with it.


I think we need to now see what happens in Ubuntu 13.04 which
supports firewalld and hence has proper zone support.  Assuming that
it doesn't block UPnP either by default in any zones, then I think we
have a good case for adding zone support to GUPnP, rather than trying
to configure firewall rules for every distro.



We will be able to test it next week. :)
While adding Connman Network Manager in GUPnP, I asked Samuel about Network Zone. He explains to me that the purpose of this feature is to modify the rules of the firewall through the network manager directly, by manipulating iptable. So alas, I think we will need to discuss with distro vendor (IF THEY USE NM + Zone). 


As I mentioned in a previous email, I suspect blocking UPnP in the
firewall is probably not a workable solution and I don't think we should
pursue this, if it is not already done.  In addition, if you read
Jussi's emails you will see that such a solution is not really desirable
as it applies one set of rules for all UPnP applications, whether they
are based on GUPnP or on other stacks.  As Jussi points out this is not
what we want.  Each application has its own set of requirements.  If we
unilaterally block things in the firewall, we will take this freedom
away from applications and their users and break existing applications.




I understand your point of view and agree on the concept.
The 'problem' is that Network Zone is here to make security at system level, not at application level. 
So we will need to deal with it, even if we don't like the rules.
There MIGHT be a possible solution, but we need to dig further. Some firewalls allow rules based on applications, not only IP & port.
In any cases, we should convince distro vendors to not block UPnP by default in all the firewall rules or to allow GUPnP/dLeyna/Rygel (if supported). 
It's not won.
And if (and I think it will) the system of Zone is going to be default one in the future release of distro, we will have many options: 1 - Deal with distro to adapt the rules to match their needs and our needs AND/OR 2 - Make a documentation to explain to users how to modify the rules to get dLeyna to work AND/OR 
3 - Provide a script to modify the rules to our needs (if doable)



Best Regards,

Mark
_______________________________________________
gupnp-list mailing list
gupnp-list gnome org
https://mail.gnome.org/mailman/listinfo/gupnp-list



Regards

--
Ludovic Ferrandis
Open Source Technology Center
Intel Corporation
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]