- Technical documentation
- API docs
Spaceify Security Model
This document describes in detail the security model of Spaceify. In Spaceify isolation between applications (sandboxing) is achieved through the use of Docker containers, and access control is enforced using Linux iptables.
The Basis: Docker and iptables
Spaceify uses two distinct subnetworks to make the distinction between the WiFi clients and the applications/spacelets running on the edge node itself. The WiFI clients are placed into the 10.0.x.x subnetwork whereas applications/spacelets reside in the 172.17.x.x subnetwork.
In the Spaceify platform, access rights are enforced using the Linux iptables. With iptables it is possible to create rules that dictate which IP address/port combination is able to communicate with which IP address/port combination.
In Spaceify each application/spacelet runs in its own Docker container, and thus, each application/spacelet has its own IP address. Further, the services that the applications/spacelets provide, listen on their own distinct ports. This makes it possible to control access rights on the level: "application A has the right to use service X of application B".
Access Control: Declaring Required and Provided Services
Each Spaceify application declares in its "requires_services" field of its manifest file which services it requires. This field lists all the services the application is entitled to use (excluding the open and open_local services that all applications can use). When installing application A the Space owner can decide based on the information listed in the "requires_services" field, whether she/he finds it acceptable that application A can use the listed services. If he/she finds this unacceptable, he/she can decide not to install the application in question. An example of a case where the Space owner might want to opt-out of installing the application might be when an audio advertisement application lists "bigscreen" in its "requires_services" field.
When the application is running it starts discovering services using the Spaceify service discovery mechanism. The Spaceify service discovery mechanism reads the manifest file of the application that is trying to discover services, and only if the desired service is in the "requires_services" field of the application, will it return the ip address and port of the service, and allow the connection to take place using iptables. If the service name is not listed in the "requires_services" field of the application, the service discovery mechanism will return an error.
Likewise, the "provides_services" field of the manifest file declares which services the application is entitled to provide. A Spaceify application can only register to the service discovery mechanism the services it has declared in the "provides_services" field of its manifest. In addition to the names of the services to be provided, the "provides_services" field also declares the types of the services in question. There are 4 distinct service types, which are listed in table 1:
|standard||Strict access control is applied. Only those applications may access this service that state that they need to use this service in the "requires_services" field of their manifest files.|
|open_local||All ip addresses from the 172.17.x.x range (applications and spacelets) can access the service freely. WiFi clients from the 10.0.x.x network cannot access this service.|
|open||No access control is applied. All ip addresses, both from the 172.17.x.x range and the WiFi clients from the 10.0.x.x network can access the service freely.|
|alien||The preferred method of communicating in Spaceify is to use WebSocket connections and JSON-RPC protocol. Alien service type can use its own connection method and protocal. Otherwise the security model is the same as standard has.|
The Special Case of Spacelets : Same Origin Policy
Two Same origin policy rules apply to all spacelets in Spaceify.
- A Spacelet can only be started by web pages that originate from the same domain as the Spacelet itself.
- A Spacelet can only be connected to by web pages that originate from the same domain as the Spacelet itself.
The first one of these rules is easy to enforce because Spacelets are always started through the startSpacelet() call of the Spaceify core. Thus it is enough that the origin header of the startSpacelet() call is checked against the manifest of the Spacelet to be started.
The second condition is more difficult to enforce because usually, all communication in Spaceify takes place over direct TCP/IP connections between the communicating entities. This difficulty has been overcome by only allowing one central entity, the ConnectionHub, to open connections to spacelets. If a web page, application or another spacelet wishes to open a connection to a spacelet, it must do it by calling the connectTo() method of the ConnectionHub. The origin header of the connectTo() call is checked by ConnectionHub, and connections violating the same origin policy are not let through.