GNOME.org
 

Re: GUPnP and Zones

On 26/04/2013 14:06, Ludovic Ferrandis wrote:

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



More information about firewall rules/zone/firewalld.

I discuss with Connman maintainer and got some good news:
Probably no 'Zone' support in Connamn like NM or Win7, but firewall(iptables) managing, yes, with API to query the status of a port/ip and an API to change it (if you have the right to do it).
So we can imagine a solution where GUPnP (in each connection manager plugin) send a query to know the status of all relevant firewall information (SSDP port for example). Depending of the white list rules, if we need to enable a network that is blocked by the firewall, GUPnP could try to unlock it. If failed, the network stay blocked.
We need to check the new NM API, and maybe in the firewalld dbus API, to know if we have these kind of API. If we have these API, then we don't need to deal with the default rules provided by the various distro, nor the Zone itself. GUPnP should just verify that 'firewalling' is enabled or not and retrieve the rules/status of the firewall info that have meaning for UPnP/DLNA.
For instance, this could be done only with NM, (and we should verify these API exist). 
The Linux connection manager, probably, won't be able to manage firewalling.
So GUPnP should probably not return 'Zone' information itself, but provide API more generic, something like GetFirewallRule or GetPortInfo and SetFirewallRule or EnablePort.
So, this way, we can take into account in our while list rules, the firewall rules already in place, and we could try to change it (if we have the right), depending of our whitelist rules. 

Ludo

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