Avoiding the Location capability

[storsjo]

Hi,

I'm developing an application which itself only needs capability which are grantable in selfsigned packages. Lately, I've thought about adding GPS functionality to this application, but since this only is an extra addition and not part of the core feature set, I'd want to avoid going through all of the signing burden just for this small additional feature.

I've accomplished this by creating a proxy server, which replicates the LBS functionality. Then, only the proxy server needs the Location capability, and the main application can remain selfsigned. Also, since this is a separate server, the main application works fine even if the proxy server isn't installed.

Currently, if end users want the added GPS functionality, they have to get a signed version of the proxy server installed, but I'd be nice to get this officially symbian signed so the proxy server sis could be included in the normal installation package.

The code to this proxy server is available under a zlib-style license (very permissive), at http://movino.svn.sourceforge.net/vi...bsproxy/trunk/.

Does anybody see any problems in getting this signed? Since the proxy sis doesn't include any gui at all, what would be tested in that case? Hopefully Symbian and/or Nokia don't have any objections to this. (The Location capability will be user-grantable in S60 3.2 anyway, this just gives selfsigned applications on S60 3.0 and 3.1 access to the same functionality, without modifying the actual platform.)

I hope that this proxy server can be useful for other developers. It consists of one ordinary server executable, and a static library containing the client-side interface. (This is made as a static library instead of an ordinary dll, to avoid possible conflicts if multiple applications use the same client interface, so they don't both have to install any separate client dll. The client interface isn't included in the proxy package either, since that would prohibit applications from working if the proxy package isn't installed.)

To use this, compile the lbsproxy project and include lbsproxy.h instead of lbs.h, change all occurrances of RPositionServer and RPositioner to RPositionServerProxy and RPositionerProxy. Then add STATICLIBRARY lbsproxy.lib to the mmp file (lbs.lib is still needed, for some of the other data structures used.) Then the location capability can be removed from the application.

I'd be happy to get comments on this.

// Martin

[ltomuta]

First the good news:
- your solution is feasible
- servers do get through Symbian Signed
- testing would be done based on a client application that you must provide and which fully stimulates the server (uses all its features).

Now the [very] bad news:
- your project is leaking the Location capability i.e. any application that has access to its interface (and the server source code is already public) can access location information without having the Location capability. This is entirely against the Platform Security paradigm, which is based on the servers enforcing its rules against all clients.

To get your server signed you will have to modify the implementation (derive from CPolicyServer instead of CServer2, define policies ...) so that it serves only your current application (SecureID check) or all the applications developed by you (VendorID check). All the other potential clients will have to be rejected if they do not have the Location capability (and any other that might be relevant).

[storsjo]

- your project is leaking the Location capability i.e. any application that has access to its interface (and the server source code is already public) can access location information without having the Location capability. This is entirely against the Platform Security paradigm, which is based on the servers enforcing its rules against all clients.

Yes, it leaks the capability, but that is kind of the point in this case. Since the location capability is user-grantable on S60 3.2, I hoped that it was a general policy decision, which could be applied on S60 3.0 and 3.1 by "blessing" the signing of this server, making location-functionality available to all self-signed apps on that platform.

But on the other hand, I sure understand that it would require quite a bit of rule bending to get a capability leaking server signed.

To get your server signed you will have to modify the implementation (derive from CPolicyServer instead of CServer2, define policies ...) so that it serves only your current application (SecureID check) or all the applications developed by you (VendorID check). All the other potential clients will have to be rejected if they do not have the Location capability (and any other that might be relevant).

Ok, good to know. I'll implement that if I really make an effort to get it officially signed, otherwise this solution, signed with devcerts (or open signed, when that becomes publicly available) will do for now...

// Martin

[ltomuta]

Martin, your intention is good but as you say a lot of bending would be needed. I guess it is up to Nokia to make a decision if they need and welcome this solution so you should contact nokia.testing@nokia.com and ask for their opinion.

Signing releases with devcerts is also a major bending of the rules so be sure not to make a practice out of it. Let's all play fair!

[Paul.Todd]

I suspect a much better solution would be to check the capabiltity of the caller and if it does not have the "Location" capabilty then display a message to the user warning them that you are going to be using the location capability.

This is similar to how RSendAsMessage works.

[storsjo]

Ah, that's a good idea!

Would it be ok to extend this concept by asking the user if it's ok to allow access without prompts for this application in the future, too?

// Martin

[ltomuta]

That would make a lot more sense and you would only have to wuery the user once. But it is not as simple ... on application uninstall/update you would have to delete it from your white list so that the next version of the application (which might have radical changes in its functionality) is not trusted by default.

And then again, it is not the calling application that migh be relevant but the requestors array ...

[Paul.Todd]

Which is why I said in my original post, that its better to emulate the behaviour of rsendasmessage.

If the person using the API wants to get rid of a prompt each session, they need to get symbian signed and include the location capability in their application, otherwise the user will be prompted each time the application is run.

Of course you can optimize the requests by keeping a single session open for the duration of your application.

[storsjo]

Instead of tracking when applications are uninstalled, another approach would be to store a hash of the application exe in the whitelist. Is there any such method available for getting a hash of the exe (e.g. through the RProcess class or something similar)?

Of course, a hash of the exe isn't enough for really verifying that the behaviour of the application hasn't changed, but the behaviour of selfsigned applications (to which the user has granted some capabilities on install) can also change due to plugins or whatever.

In principle, the requestor info is more relevant yes, but on S60 3.2 where this capability is user-grantable, the user still just accepts it on application level.

On the other hand, as Paul suggested, just prompting every time might be an adequate compromise.

// Martin

[sorbox666]

Did this story ever resolve or did it just go quiet?

I think that most of us agree that the Location capability should be user grantable:
1) The new S60 v3.2 allows Location to be self-signed.
2) A Java MIDLET on an N95 allows GPS access, albeit a prompt to the user (this is not problematic).

So, is there a solution for C++ developers on S60 v3.1? Can the capability be grantable via a firmware upgrade, or is it possible to sign and provide to us an application such as the one suggested in this thread? Such an application can be written, today, using Java so there is no security concern if it were to be released in C++. Having no (self-signed) GPS access in C++ is just a nuisance and not a security concern.

[storsjo]

It wasn't resolved any further than what was discussed in this thread, for my part at least. My personal conclusion is that I probably will keep on using the proxy for beta testing, but I'm considering getting the particular application symbian signed for that use case.

// Martin

[sorbox666]

Why don't you just code up the proxy in Java? You can communicate between Java & C++ using standard networking. Java allows you to create a server socket (ServerSocketConnection) on 127.0.0.1, which you can then connect to from C++.

I'll probably use this "solution" if nothing from Symbian pops up.

[storsjo]

Creating such a proxy in Java would be quite an interesting solution, I never thought of that. However, for my use cases, I'd rather not mix in a separate Java application. Or could this be made completely transparent as with the native symbian server?

// Martin

[fmoratti]

Hi to All,

first of all i want to thank Martin for the great job about Movino, i'm pubblishing my post to inform every all thath i've solved the question about Location capabilities, signed application and the other troubles.

I've replaced the PositionListener class (and header) from the movino project with a new "Active Object" Class.
The new class, called by me GPSPeriodical, connect via standard Socket to the GPS device, grab raw data by Bluetooth connection and transform the RMC NMEA sentence in decimal latitude and decimal longitude.
After this, if i have the "engine" connected, using this code, i can send position to the movino server:

TReal64 latitude(0.0);
TReal64 longitude(0.0);
TReal32 accuracy(10.0);  //HardCoded value
		
latitude = GetLatitude();
longitude = GetLongitude();
		
if(latitude && longitude && iEngine && iEngine->IsConnectionReady())
	{
	TBuf8<50> buf;
	buf.Append(2); // has latitude, real64
	AppendReal64(buf, latitude);
	buf.Append(2); // has longitude, real64
	AppendReal64(buf, longitude);
	buf.Append(1); // has accuracy, real32
	AppendReal32(buf, accuracy);
	iEngine->SendData(KMovinoDataPosition, buf);
	}

I've used this link as start point: http://wiki.forum.nokia.com/index.ph..._Bluetooth_GPS

Good work and sorry for my English.

Daniele

[fmoratti]

PS: i've tried the Java IPC solution, but the alert every time that i would to access BT GPS is very boring.
I've also tried the python solution embedding a python script in a Sym C++ application, but python script fails on importing socket library locking the symbian application.