Roundtable discussion: Application Security [answered]

asked 2014-02-12 13:26:05 +0200

AL13N
6834 ●79 ●106 ●111

updated 2014-07-25 11:47:33 +0200

jiit

2678 ●32 ●58 ●59

admin

This thread is intended as a follow-up to the community roundtable discussion about AppSec at FOSDEM 2014:

It is both the interest of Jolla and the developer community and users to have increased application security. The main point of this discussion is to find a way to deliver a reasonable level of Application Security without compromising usability for everyone.

Security is in multiple levels:

... (forgot)
... (forgot)
what Apps have access to
App <-> OS communication (hardware/services?)
App <-> App communication

Here are the most prominent ideas that came up:

no additional security (but... no security)
POSIX security (a good starting point)
AppArmor and the likes (but they are file-based only)
SELinux (more for limiting the root user, not really about app security, plus, everyone just turns it off)
complete sandboxing (too inefficient?)
containers (too much overhead?)
apps having different UIDs and being in different cgroups, communicating via DBUS to other apps and/or system, this being secured by policykit (which is part of systemd these days)

Some other points of interest:

the (dis-)advantages of on-demand security popups vs pre-init security pop-ups
the flexibility of "security policies"
NOTE: most of the app security, is actually something for mer/nemo

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

edit retag flag offensive reopen delete

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:49.705765

Comments

Could SELinux approach help here?

sjtoik ( 2014-02-13 09:02:57 +0200 )edit

ah, this was talked about too, i remember now, but no, it might help in some way, but it's only filebased, any kind of inter-app communication and it's more meant to limit the root users

AL13N ( 2014-02-13 10:18:50 +0200 )edit

3

AL13N, SELinux is much wider than just file access. Inter-app communication is done through any kind of sockets and shared memory and is equivalently covered by SELinux. DBus access is protected by SELinux as well.

There is nothing in SELinux that is really about root users only. I wonder where your misinformation comes from. Perhaps this visual guide to SELinux policy enforcement might help to clear up misunderstandings? http://opensource.com/business/13/11/selinux-policy-guide

abbra ( 2014-02-16 12:11:27 +0200 )edit

1

@AL13N, just read link by @abbra above and ask someone from osso/maemo/meego oldies in Jolla team to go through contacts and pull from closet SELinux experiments made for N900 and N9, they should fit you perfect if you can't find anyone - ask @abbra or me.

silpol ( 2014-02-16 21:19:03 +0200 )edit

I wonder whether it has been considered to create a very strict JavaScript API for app development? Say, devs create an app in pure QML and JS, and any OS or hardware functionality is accessed through API methods provided by the system? Keeping apps in their bounds, and even adding fine-grained permission control would be a piece of cake, JS would guarantee loads of potential app developers and getting started against a fixed set of API methods would be easy. Not sure whether this is feasible with regards to the technology stack, but I'd love it pretty much :)

tokaru ( 2014-02-16 22:25:17 +0200 )edit

7

answered 2014-02-13 13:24:32 +0200

AL13N
6834 ●79 ●106 ●111

my personal opinion is that a combination of different UIDs, apps and OS communicating via DBUS (perhaps QML wrappers using DBUS could be easily done, making it easier for the developers) and the whole thing secured via policykit (which iinm could give the app rights to both files and specific DBUS calls).

if there's a sane policy where the user doesn't get spammed by the on-demand access requests, this could work well, and not only for security, but for additional functionalities as well...

if the policy says 'allow', the app silently get access, if it says 'deny', the file access or DBUS request fails (the app can handle this), if it says 'ask', the user could get a popup requesting the access and he could then allow/deny and 'remember' the setting.

if this is done well, it might even allow for different security profiles during initial setup.

edit flag offensive delete publish link

3

answered 2014-02-16 18:09:56 +0200

qwazix
2310 ●27 ●37 ●42

Providing a sandbox that can be enabled/disabled per-app would be an ideal solution IMO.

There are various apps that try to get information from your phone that they don't actually need, but other times the sandbox is overwhelmingly restricting (for example the simple workflow of downloading a file editing it with an editor and reuploading with ftp is completely broken with a per-app sandbox).

Allowing the user to specify a level of trust for each application would allow ultimate productivity for trusted apps and complete sandboxing for games and other content consumption apps that do not need to access sensitive information.

edit flag offensive delete publish link

3

answered 2014-09-03 22:46:42 +0200

shfit
3003 ●30 ●38 ●41

I have no idea how "light" the containers are or if its concept is in any way applicable to a mobile OS, but heck, i'll just throw it out there: what about docker? Sure, its meant for server virtualization and it might be overkill, but it has tons of support and mobile devices are becomming more powerful by the day. Who knows, maybe one day this might be a viable approach to sandboxing apps.

edit flag offensive delete publish link

2

answered 2014-02-16 02:13:56 +0200

sebsauer
121 ●1 ●2 ●5

updated 2014-02-16 02:21:31 +0200

Some brainstorming:

Requirements:

some resources (wifi, contacts, notes, dbusiface, ...) need access-protection and -control
some apps/libs/system have complete private data (eg settings)
some apps should have access, others not
users/apps/libs/system need to differ allowed/denied to resource x for accessor y
users/apps/libs/system need to be able to control and edit those

Needed for devs:

define what own app needs to access
define new protected resources provided eg by there apps/libs
be sure those cannot be manipulated later (after deploy)

Needed for users:

know about that, beforehand and on use
know what happened afterhand, eg access logging
control/edit and revoke eg all access to contacts xor define app-contacts vs phone-contacts (different/dup resources per app/app-group)

What resources need to be protected:

access to filesystem (read, write, execute)
access to dbus-interfaces down to some methods for world, some need protection
apps need secure/trusted storage for settings (so, foreign apps not can manipulate), passwords (eg think N9 like /secure store-space and/or transparent encrypted QSettings and/or kwallet-like password/storage manager).

How:

unique identifier per app
needs to be passed around or be able to fetch info who tries to access
some kind of signing done by dev with his keys (origin-control, trust dev not binary blob app, update-verification of origin)

edit flag offensive delete publish link

Roundtable discussion: Application Security [answered]

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:49.705765

Comments

4 Answers

Question tools

Stats

Related questions

Roundtable discussion: Application Security [answered]

If you have ideas to solve these issues or can come up with a good compromise, please chime in to this discussion!

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric close date 2015-01-21 10:07:49.705765

Comments

4 Answers

Question tools

Public thread

Stats

Related questions

The question has been closed for the following reason "the question is answered, an answer was accepted" by eric
close date 2015-01-21 10:07:49.705765