GNOME.org
 

Re: Security: Context filtering

On 28/06/2013 15:23, Ludovic Ferrandis wrote:

On 28/06/2013 12:09, Jens Georg wrote:

On Do, 2013-06-27 at 18:10 +0200, Ludovic Ferrandis wrote:

CCing on rygel list as well.


Sort of security in DLNA.

Introduction for UPnP/DLNA newcomers.

UPnP/DLNA have been developed with the concept that all components are
running on trusted network.
At this time, only HND (Home Network Device) were available and it was
easy to define or setup a trusted network.
Now we are in a world of mobility. You can connect devices from
everywhere (restaurant, hotel, public places, ...)
It's to be able to handle such mobility that a new class of device has
been defined, the MHD (Mobile Handheld Device).

Security issues appears with the development of the wireless
connectivity. Do you want your photos to be shared on a public network?

Security issues are not the same for servers and clients.
On the server side, you probably don't want to be visible and share data
on untrusted networks.
On the client side, you probably don't want to connect to untrusted
servers that can send you damaged data.

The proposed solution is to managed a white list of trusted networks.
This is not a strong security system with password, trusted encrypted
password server etc...


How would it work?

The solution is not new, is the one already implemented in Rygel. It's
based on a white list.
The white list could be composed of ip address, SSID or network type
(eth, wlan, ...).
Only interfaces defined in the white list will be trusted, the other
ones will be rejected.
An empty white list means all interfaces are trusted. This will ensure
compatibility behavior with applications that already use GUPnP but
doesn't manage white list.


How to implement it?

The solution is to implement the white list management in GUPnP, BUT NOT
the white list settings/file management.

The concept is to manage the white list in memory by GUPnP. GUPnP is
linked to an application, so the white list will be available only for
this application.
The file/setting will be managed by the applications (Rygel, dLeyna,
others).
GUPnP will filter out available GUPnP context based on the white list.
The filter is dynamic, that means if the white list is updated by the
application during it's lifetime, GUPnP context will be made available
or discarded accordingly.

The comparison will be strict. "eth" will not match "eth0", "eth1".


Impacts on GUPnP applications?

Applications that will use the new GUPnP library but don't use the white
list API, will have the same behavior, as the GUPnP default behavior is
to disable the white list feature.
Applications, like Rygel, that manage their own white list and would not
use the new API, will have the same behavior. I will post another email
in Rygel mailing list about Rygel application itself.



API proposal:

GUPnP: The white list APIs should be part of GUPnP Context.

void gupnp_context_white_list_enable(gboolean enable)
Enable or disable the white list.
When disabled, it will broadcast all available context.
This will also allow to build the white list using add/remove/reset API
without performing filtering at each call of these functions.
When enabled, it will filter out all available contexts, accordingly to
the white list.
When enabled, each call to add/remove/reset has an immediate action.
This function doesn't change the content of the white list.

gboolean gupnp_context_white_list_is_enabled(void)
Return the status of the white list.


ok.



gboolean gupnp_context_white_list_add_interface(gchar* interface)
gchar* interface: is a semi colon separated string list of interface
name. ("eth0" or "127.0.0.1;192.168.1.1")
Add new interface(s) to the white list. It has an immediate effect only
if it's enabled.
Return false if one can't be added to the white list.


That's not good. either _add_interface adds a single interface or it
should be called _add_interfaces/_add_interface_list. Also I'm not sure
I like the CSV approach.

Second, as in Rygel, this is not only about interfaces as such, as it
can also cover SSID, the IPv4 network, (a IPv6 prefix in future), an IP
address and a network device name. The reason it's called interface in
Rygel is because that's where it comes from, network interface names
only.


gboolean gupnp_context_white_list_remove_interface(gchar* interface)
gchar* interface: is a semi colon separated string list of interface
name. ("eth0" or "127.0.0.1;192.168.1.1")
Remove new interface(s) to the white list. It has an immediate effect
only if it's enabled.
Return false if all interfaces are not found, true otherwise.


Same notes as add.



gchar *gupnp_context_white_list_get_interface(void)
Return the list of interfaces in the white list.
It's a semi colon separated string list of interface name. ("eth0" or
"127.0.0.1;192.168.1.1")


get_interfaces. And maybe a char[] or even a GList



void gupnp_context_white_list_reset_interface(void)
Remove all interfaces in the white list.
It doesn't change the enabled flag.
As for add/remove, changes are immediate or no, depending of the enabled
flag.


why not _white_list_clear?



Firewall Zone

[...]

The firewall installed by Network Manager is called FirewallD and
provide a dbus API.
The only feature that interest us is the notification when the current
active zone is changed.
This use case should be exceptional, but we can manage it.
In this case, GUPnP could perform a 'Refresh'. Depending of the new
active firewall rules, servers will appears or disappears immediately in
application (like dleyna).
Otherwise we should wait, for the disappears case, the SSDP time out
that is 30 min.


For the record, fedora is using firewalld as well.



This feature should be implement in the Network Manager plug-in of GUPnP
Connection Manager.

As I said, the feature is simple to implement, but it's very low
priority.

Any comments are welcome.


Agree.


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



Based on my second email and your comments, here is a second set of APIs:

void gupnp_white_list_enable(GUPnPContextManager *context_manager,
gboolean enable)
Enable or disable the white list.
When disabled, it will broadcast all available context.
This will also allow to build the white list using add/remove/reset API
without performing filtering at each call of these functions.
When enabled, it will filter out all available contexts, accordingly to
the white list.
When enabled, each call to add/remove/reset has an immediate action.
This function doesn't change the content of the white list.

gboolean gupnp_white_list_is_enabled(GUPnPContextManager *context_manager)
Return the status of the white list.

gboolean gupnp_white_list_add_entry(GUPnPContextManager
*context_manager, gchar* entry)
gchar* entry: Network or device information string.
It could be the ip address, SSID, device name, ...
Add a new entry to the white list. It has an immediate effect only if
it's enabled.
Return false if it can't be added to the white list or already exists in
the white list.

gboolean gupnp_white_list_remove_entry(GUPnPContextManager
*context_manager, gchar* entry)
gchar* entry: Network or device information string.
Remove the entry to the white list. It has an immediate effect only if
it's enabled.
Return false if failed to be remoded or not found.

GSList *gupnp_white_list_get_network_list(GUPnPContextManager
*context_manager)


Should be;
GSList *gupnp_white_list_get_entry_list(GUPnPContextManager *context_manager) 
Click to fast on the send button.


Return the list of entries in the white list.
NULL if no entry.

void gupnp_white_list_clear(GUPnPContextManager *context_manager)
Remove all entries in the white list.
It doesn't change the enabled flag.
As for add/remove, changes are immediate or no, depending of the enabled
flag.

Ludovic



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