API Security Model

asked 2014-01-03 21:14:50 +0300

AL13N
6834 ●79 ●106 ●111

updated 2014-01-06 01:56:46 +0300

rainisto

6348 ●69 ●98 ●112

moderator

(see here for more info on what i mean with API)

apps should be able to call API, but there should be some kind of simple, non-limiting and easy way to secure these API's

first, i was thinking that a general access listing could be provided by Jolla, since all apps and OS have these API's, the Jolla people can decide on a sane default access for each API, (eg: no mail/sms/social_media/etc... )
secondly, these should be editable on each device seperately
app installs or updates should extend this list (with the default access level (none, ask, certain apps, all)
if an app starts for the first time (or update, or an API has become installed), (if the level is ask) the system should notify the user that this app, he's running for the first time, is requesting this or that API from other apps or system that if they want to or not. at this point, the user can select ask later, or allow (for now) or whatever action for each API independantly
Since users can modify default, they could for example select that facebook API's (all, or selection) are always denied
the good point now, is that APP that want this kind of API, should still run.
This allows for instance to run games and not want these games to post scores on facebook
This also allows for apps to send emails or sms automatically, without confirmation, because the users would have validated this, or have access to contacts or whatever...

The sky is the limit here as well...

edit retag flag offensive close delete

Comments

8

Usually in the F/LOSS community reputation alone is enough, as also happened with one app in the store. But more problematic is that the overview in the store only shows that said app has 190 votes - not that it has > 3500 downvotes.

Tanghus ( 2014-01-06 03:09:51 +0300 )edit

1

@Tangus the real problem is that some apps "phone home" and some privacy aware people don't want that.

AL13N ( 2014-01-08 14:10:15 +0300 )edit

2

Privacy aware people also know how to use iptables to block outgoing connections. But I can see the point that some people might want to have GUI for iptables.

rainisto ( 2014-01-08 14:32:03 +0300 )edit

1

@rainisto iptables does very little in preventing a program to access contacts, if one does want to allow the program to communicate but prevent taking your contacts with it (please see my answer below)

jusic ( 2014-01-08 14:45:33 +0300 )edit

2

@jusic Yes, thats why we already have privileged-group on device to protect important data like facebook contacts etc. Harbour applications will not have access to privileged group and they cannot steal that data from the phone. See "ls -la /home/nemo/.local/share/system/privileged |grep d---"

rainisto ( 2014-01-08 14:57:58 +0300 )edit

71

answered 2014-01-06 03:21:56 +0300

jusic

1006 ●5 ●6 ●6

updated 2014-01-06 04:51:43 +0300

Safeguarding user's data on the API level is very important. Especially with closed-source apps, there are many nasty companies that just want to slurp your private data into cloud without your approval/knowledge. Even Harbour screening process may not prevent this.

There are ways to do this safeguarding well and badly.

For example, the Android security model is quite bad, from the usability point of view. It's all or nothing (i.e. accept/deny all requested permissions), and the user is asked only once at the install time. Aegis is similarly horrid, with permission manifest files etc.

However, iOS's security model is quite good. No questions asked at the app install time. But when you run an app, and it wants to use a privileged API, the user gets a pop-up, e.g. "This app wants to access your Contacts [allow] [deny]". This question is clear even for non-techies.

The user should be asked every time an app wants to use their contacts, location, etc. And they should be provided an option to set the answer permanently (maybe in global app settings) if they get tired of asking.

Example use case: A user downloads a Facebook app to use, but they don't want to give their contacts to it. In Android, this is not possible. On iOS, the user just denies access to Contacts when they get prompted. All good, the user is in control. No crusty manifest files needed.

As to the technical side, I think there are many ways to achieve this, as @AL13N suggested already some. The basic idea is that when an app tries to open e.g. a contacts API, the contacts API init/constructor method consults the security system, and by default, it asks the user what to do. Think "sudo" prompt here (for a specific resource, not global root access), it's very analogous to this.

Safeguarding user's data is an orthogonal goal to device openness and being "as Linux/Unix as possible". Security can be done properly (and without harming usability) while still maintaining an open platform. The worst option is neglecting to do this safeguarding at all.

edit flag offensive delete publish link

Comments

Well Qt5 (http://qt-project.org) is opensource project, so you are free to make and suggest security patches for example to contacts API ini/constructor. And if you make good enough security framework and patches, I would expect to see that happening to hit devices in couple of years...

rainisto ( 2014-01-08 14:40:01 +0300 )edit

You could also suggest this in Qt mailing list and open discussion in there, as it would fundamentally needed to be done in Qt level. As we don't have the power to change how those APIs work without everyone using Qt agreeing. Will BB, Windows and Mac users also agree on that security model?

rainisto ( 2014-01-08 14:44:30 +0300 )edit

1

@rainisto Thanks for the info. In terms of the Qt APIs, I think they support these features already. For instance contacts and location sources have error codes/states like "permission denied" or "no resources available". It is the task of the platform/backend to define and handle the access policy.

jusic ( 2014-01-08 16:15:14 +0300 )edit

I'd gladly chip in but does this fall more under Mer or currently closed part of Sailfish?

jusic ( 2014-01-08 16:17:05 +0300 )edit

1

Not really, we are using Qt5Contacts, Qt5Location, so middleware is from open source. Closed part is merery the UI (+bits).

rainisto ( 2014-01-08 16:24:45 +0300 )edit

21

answered 2014-01-04 11:00:44 +0300

AL13N
6834 ●79 ●106 ●111

updated 2014-05-28 19:31:37 +0300

if the API is using DBUS, systemd-logind (with policykit actions) could be used to secure this.

also, it would be interesting if the apps are sandboxed:

cgroup container per app
harbour submission decides on what user? (with this, i mean that not every app should have it's own user, sometimes some apps should really have the same user)
running the app in another user

security levels should be something like: (keep in mind this is a combination of (source app, dest app/core, which API (or all APIs))

no access (don't ask me)
ask me if i want access or not
allow always (don't ask)

also, tunability of apps should go in the following levels:

general defaults for everything (not directly used, but copied when something changes due to install/update)
list of complete access from certain apps to other apps
user overridable lists of all API's

NOTE: an interesting read on namespaces and cgroups.

edit flag offensive delete publish link

Comments

2

Yes, the started apps are currently no systemd units. If this was the case, all the above could be nicely implemented, and systemd will gather even more sandboxing mechanisms in the future.

zonque ( 2014-09-14 22:04:06 +0300 )edit

13

answered 2014-04-23 11:26:43 +0300

dez

7104 ●78 ●94 ●94

moderator

There are already a lot of widely used and well-developed security policy enforcement frameworks (SELinux, Grsecurity, AppArmor, Tomoyo etc.), so this bicycle should not be reinvented, especially taking into account this is security and it requires experience and attention to details. So, I think that:

one of those frameworks should be chosen as the base security system
corresponding set of policies should be created
APIs should be evaluated on how they can be integrated with chosen framework policies. E.g. while file systems and (maybe) D-Bus are ordinary protected by those frameworks from the beginning, Qt API isn't protected and data which should be covered by different policies can be mixed in the same database. It will be much better if only file access and some RPC (e.g. D-Bus) should be supported and used.
proper UI hooks should be developed.

edit flag offensive delete publish link

8

answered 2014-01-10 21:50:45 +0300

javispedro

2402 ●33 ●44 ●42

http://javispedro.com/

updated 2014-01-10 21:52:18 +0300

I'm going to mention the webOS "jailer", just because it is the only working implementation of sandboxing I know on a GNU/Linux operating system (Android isn't). I'm not saying it is the best one nor that it is the one I want.

http://www.pabloendres.com/wp-content/uploads/2012/04/WebOS-Security-v1.1.pdf

Basically, "native" apps (the others are webby apps and thus use a different sandboxing strategy) run as a different UID (each). Additionally, they run inside a chroot (a new chroot for each instance). The jailer also does some bind mounts from outside the chroot to inside to "poke some holes" (e.g. ensure that /opt/$PROGRAM/ points to the program directory, ensure that /home/$USER/.config/$PROGRAM points to the program config dir, etc.). Bash-script simple. The chroot gets destroyed when the program terminates.

Apart from this, webOS used its own "D-Bus clone". From a user point of view, it is basically iOS's model (you get asked whenever a program is trying to use D-Bus to contact e.g. positioning services).

edit flag offensive delete publish link

Comments

If you need a "jailer" on GNU/Linux, try firejail You can find some useful examples in this blog It would be useful (for advanced users) if someone ports it on sailfish os

yuri ( 2016-02-24 13:59:14 +0300 )edit

5

answered 2014-04-23 11:31:19 +0300

dez

7104 ●78 ●94 ●94

moderator

Concept of trusted vendors and applications can be used in communication with end user: if user trusts e.g. Jolla (or Yandex, Google etc.), user can mark this vendor as trusted and all applications signed and supplied by Jolla can automatically get requested permissions (while user can always review what permissions specific application has). Before installation user should see the list of requested permissions and has a choices:

"Allow everything" == trusted application
"Allow selected"
"Always ask" (with ability to set "Do not ask later")
"Deny"

edit flag offensive delete publish link

4

answered 2014-01-06 02:01:40 +0300

rainisto

6348 ●69 ●98 ●112

moderator

updated 2014-01-06 02:05:09 +0300

I don't like the idea. Most users always press "Yes" and other half doesnt even understand the question. We dont want to inherit the failure of Android API security model nor reinvent the Aegies. I want to keep the device open and as Linux/Unix like as possible.

Sandboxing standalone calculator apps with cgroups could be feasible.

edit flag offensive delete publish link

Comments

23

I agree that both Android and Aegis models are horrid. However, I find iOS's model quite good. E.g. "This app wants to access your Contacts [allow] [deny]". This question is clear even for non-techies. If I don't want to give my contacts e.g. to an FB app, but use it otherwise, this is important.

jusic ( 2014-01-06 02:27:15 +0300 )edit

14

I think the user should be asked every time an app wants to use your contacts, location, etc. And they should be provided an option to set the answer permanently (maybe in global app settings) if they get tired of asking. Simple hooks in Harbour-approved API open/init methods.

jusic ( 2014-01-06 02:35:13 +0300 )edit

1

i'm not trying to reinvent the aegis thing, nor do i want to be limiting... if you read carefully, it means that default access can be set by Jolla and i wouldn't even care if you set security level during wizard by default to all open, for that matter...

but even QA cannot test everything, and us users want to be secure in knowing that apps won't misuse our contacts/send sms/datamining or whatever... it's a reality that has to happen...

AL13N ( 2014-01-06 09:06:54 +0300 )edit

1

plus as i said, with my approach, we can avoid all the pitfalls and still have app <--> app collaboration.

the things i propose will not hamper efficiency neither and still be as secure as any user wants (and by default what jolla wants)

eg: a security level setting somewhere is enough and if you want to keep it all open... that's just fine by me, as long as privacy aware people can set it higher...

AL13N ( 2014-01-06 09:10:05 +0300 )edit

after some thinking, as a nice example, the API Security model would be interesting in the settings app, for instance, the settings app could then allow via DBUS for each app to register settings in their dedicated per app settings. in a similar way, a few apps (jolla or other selected few) would be able to register settings in other places in the settings app. and this can be allowed by default for only those apps.

AL13N ( 2014-01-12 13:07:50 +0300 )edit

4

answered 2014-05-28 16:53:45 +0300

ofutur
61 ●2 ●3

You could copy the model adopted by BlackBerry which lets you untick permissions when you install the app. Every permission is detailed, like on Android, so it's not difficult for users to decide what to do. Once the app starts or when activating certain features, it will ask you for permissions again if it tries to do something requiring a permission it doesn't have.

There is a permission screen, like on Android, where you can see all the permissions an app needs and you can filter per permission to check which apps can use your location per example. What's missing is something like CyanogenMOD's Privacy Guard where you can decide to send mock data if the app can't run without a specific permission.

edit flag offensive delete publish link

3

answered 2014-01-06 21:50:31 +0300

hardcodes.de
5576 ●64 ●83 ●82

I also think it's a sad reality that we need more security features and I share AL13N's thoughts that it can be done with user satisfaction and freedom for developers. Just make it an option.

The earlier it is done, the easier is the migration = still not so many apps around here.

edit flag offensive delete publish link

Comments

Well 'earlier' can mean many things, some of the security features suggested in here, mean writing new security framework from scratch, which means several man years of work, in which case it would mean that earliest you see the full blown API security coming in few years.

rainisto ( 2014-01-09 18:28:22 +0300 )edit

2

But having said that we are looking into ways of improving the security, and hopefully find ways to reuse some existing oss frameworks in order to get improvements in this year :-). And we are also improving security on other areas as well, not only API security.

rainisto ( 2014-01-09 18:30:11 +0300 )edit

apparmor? selinux? a lot of work to implement useful policies that map onto user-relevant concepts like contact lists, but secure against binary blobs unlike any "API" level security you can come up with... a binary blob with filesystem access can steal any data it likes no matter how tight your API

mornfall ( 2014-01-10 22:41:43 +0300 )edit

2

answered 2014-05-28 17:29:11 +0300

alci

1024 ●26 ●38 ●48

updated 2014-05-28 17:29:48 +0300

Here is how Ubuntu Touch sees the problem (and their solution, AFAICT):

Ubuntu Touch and user privacy

edit flag offensive delete publish link

0

answered 2014-06-01 22:15:22 +0300

schmittlauch
4334 ●60 ●75 ●71

For limiting e.g. filesystem access, you could use AppArmor profiles for each app. AFAIK AppArmor is much easier to use and configure than SELinux which is currently being integrated into Android. Not having that much experience with it, I can't tell wether it can be used to manage access to certain APIs though.

edit flag offensive delete publish link

API Security Model

Comments

10 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Stats

Related questions

API Security Model

Comments

10 Answers

Comments

Comments

Comments

Comments

Comments

Question tools

Public thread

Stats

Related questions