The problem with Aegis was inability to actually fully control it even when user had super privileges (sudo). This took away control from the user to those who were able to sign the binaries. While in theory something like Aegis can be good (i.e. granular security for various aspects), in the end, user should be able to take control over it or override it when needed (given that user escalated access rights with something like sudo and etc.).
Hillel. On Tue, Dec 11, 2012 at 4:24 PM, Jussi Sainio <[email protected]> wrote: > 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 > >
