On 11.12.2012, at 15.51, David Greaves wrote:

> It is about time we started to discuss security and privacy in the Mer 
> context.
> 
> Mer is aimed at device vendors and there will be different concepts and
> implementations of security technologies in the layers above (and below) Mer.
> 
> Given the initial set of builds on Mer includes Nemo, Plasma Active and now
> Sailfish I think it makes sense to include issues around "apps" as well as
> things like network access or data encryption.
> 
> Rather than re-invent their wheels I'll ask if we have any thoughts or
> requirements from our downstreams already?

Great! I think this is a very important issue. It pays to look around for 
existing solutions and gather the best things from various worlds, and then 
some. Here are some thoughts I discussed about on #jollamobile today, further 
elaborated:


Apps, User point of view:

If a random app is downloaded from a random source, it must not be let to fetch 
contacts or photos directly. The user must be aware of this and asked 
beforehand. Then, it's the fine art of choosing a usable level what should be 
asked and how often. I think the level on iOS is about right for most users, 
"This app wants to use your photos/contacts/calendar/location [Allow] [Don't 
allow]". (Methinks there could be even an [Advanced...] button.) Also, it was 
discussed on the IRC channel that the Android solution "Allow all/none at 
install time" is a very inadequate level.

As suggested on the IRC channel, "the trick is not to stand in the way of the 
user, but to stand in the way of the data octopuses". If the user trusts an app 
for good, they must be able to give (and remove) permanent permissions for it. 
Therefore, there must be a 'registry' which takes into account what right have 
already been given to a specific app. Then you can do basic "always allow" or 
"ask me every time" kind of stuff.

While the Android "Allow all/none" solution is "rubbish", Android documents do 
provide some insightful aspects (and also technical solutions) that have to be 
taken into account [1].


Apps, Technical point of view:

Regarding the filesystem, I think that one clean solution would put all private 
data under a specific unix group/ACL privilege. When an app wants to use 
something from a private data directory (such as calendar, photos, contacts), 
it must ask for increased ACL privileges to read that directory/file. This 
solution would still allow nice and clean filesystem access for the user (all 
privileges in a terminal, for example), but when an app is launched, by 
default, some of the permissions are dropped before exec()ing the binary, and 
then they are later granted by the user or by the registry via a library.

It was suggested on the channel that Unix credentials are not enough. I agree, 
that not everything is a file on Unix anymore, so a credential system has to 
give rights other aspects to the system as well, such as TCP sockets and "make 
a call over GSM". These have to be thought out, what is the best practice to 
achieve this without making developer's (and user's) life too annoying.

It was also suggested on the channel that Nokia/MeeGo Aegis should be fairly 
close solution. In my opinion, Aegis design seems to be fairly complex. I'm not 
an expert on Aegis, so it might have its inner beauty that I don't comprehend. 
I'm not sure if Aegis is open source, at least I couldn't find the source code 
quickly. Unlike in the stock Harmattan Aegis configuration, user access to 
true, full root privileges should not be restricted. But at least the 
documentation gives some pointers, what was taken into account in MeeGo. [2] 


Data encryption:

I think most data should be encrypted, inaccessible after a boot-up, encrypted 
using a device pass code (if used). As default, a lock screen should ask this 
same pass code, but it does not necessarily have to drop the encryption key 
from memory, to allow programs to use their data while running in background.

If multi-user is to be supported, then the user's pass codes should be able to 
unlock the device.


Refs:

[1] http://source.android.com/tech/security/
[2] 
http://harmattan-dev.nokia.com/docs/library/html/guide/html/Developer_Library_Developing_for_Harmattan_Harmattan_security.html

Cheers,
--jussi

Reply via email to