Re: Security: Context filtering

[Jens Georg <mail jensge org>]

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.