Ask / Submit

per-app network access (and data roaming) control

asked 2014-12-10 18:02:12 +0200

mornfall gravatar image

It would be very useful to be able to limit which apps can go where online, and if they can do so on WLAN, home cellular network or in roaming... One way to implement this would be to run each app under a separate user and use iptables (which can set per-user rules) to enforce the restrictions.

While a simplistic rule editor would be a very good start and already would put Sailfish ahead of competition, an interactive mode where most apps are not allowed anything by default but rejected packets cause an interactive dialog to appear with options what to allow the app to do and when. (I.e. options like: allow access to this domain on: wlan/cellular/anytime, allow this app any internet access on: ... you get the idea). Besides the currently fairly pressing need for cost control, this has a hugely important role in retaining some of our privacy.

(And privacy was supposed to be a selling point of the Jolla tablet, so I would very much hope something like this makes it into SailfishOS -- including on the phone...)

edit retag flag offensive close delete



Yes i agree it will be not bad to have it. And i want to add something with it, that if an app try to have access with an interface. It should be notified with clear information. The app xxx want to have access through this interface.

cemoi71 ( 2014-12-10 18:19:33 +0200 )edit

It would be even nicer to have a generic framework for app permissions. Unfortunately, as you say, it's not a good fit for the underlying Linux system, where permissions are mostly managed by user. Maybe use kernel namespaces and assign each app it's own namespaces? Then one could set e.g. WLAN permissions without needing a different user for each app.

dthierbach ( 2014-12-10 20:53:08 +0200 )edit

@dthierbach I think that user-per-app is a viable approach here... while apparmor or selinux would be (probably) slightly more secure, the main 2 reasons we don't use user-per-app on desktop is a) convenience and b) X11 ... if this user-per-app thing is implemented, we can implement security policies ourselves, without having to bother jolla too much (of course, if jolla would work on particular policies that'd be splendid). The “magic” of this approach (and I believe this is what jolla had in mind at some point at least) is that you don't really need a “generic framework for app permissions”. You can build small tools for each policy area separately and maybe eventually pull them together via user interface. A sort of bottom-up approach (instead of what seems to be your suggestion, a top-down approach where a big unified framework is made up-front).

mornfall ( 2014-12-11 14:13:07 +0200 )edit

@mornfall: If you can come up with a good concept to manage "one user id/app", great, but I see multiple problems: Apps change frequently, you need to access shared data (that means groups and managing group membership), etc. And yes, you still need a generic framework: You want a central place to set and edit those permissions, and a manifest that documents which apps need which permissions. Actually implementing these permissions will need to modify system files all over the place, and you don't want to keep your state in that.

dthierbach ( 2014-12-11 16:43:26 +0200 )edit

@dthierbach What is there to manage? Apps in the launcher are already “special” ... running them under their own uid isn't a big change -- all you need to do is create the users for installed apps, and create a user when a new app is installed. You only need to manage things when you want to remove permissions from apps. Initially, you can just shove everything into the 'nemo' or whatever group and use group permissions instead of owner permissions on data. Nothing to be managed. However, immediately, it becomes possible to write something to manage iptables-based network permissions. It also becomes possible to move resource ownership to a special group and limit membership of users in those groups. These two are about management, yes. But they don't need to be integral part of the system from the start.

mornfall ( 2014-12-11 17:07:28 +0200 )edit

1 Answer

Sort by » oldest newest most voted

answered 2014-12-10 20:12:22 +0200

tigeli gravatar image

There is ConnMan session API ( which we don't use (yet).

We need better control of handling of network access/restrictions but it needs to be easy enough for the end users, if we end up popping up dialogs all the time the user will go to "yes, yes, allow, allow"-mode without reading what is requesting what. The need has been acknowledged though.. :)

edit flag offensive delete publish link more


There should be definitely a way to assign permissions to an app, without dialogs. It should be handled at install time, not when the app is run.

dthierbach ( 2014-12-10 20:54:49 +0200 )edit

At install time... or not. On Android nearly every application ask for everything, and you don't know why as it is not in relation with an action you just made. So to you have no choice but to acknowledge or reject the app altogether. Being able to grant certain right when you do something precise in the app would be much more meaningful.

alci ( 2014-12-10 21:30:14 +0200 )edit

Yes, @dthierbach, I agree with @alci here: install-time permissions end up not doing anything because all apps get all permissions “just in case” and it's an all-or-nothing affair. Not happy? Don't use the app. Not my kind of system...

mornfall ( 2014-12-10 22:17:34 +0200 )edit

@tigeli well, it may not be the default mode of operation -- but a very restrictive profile (even if it bothers me with dialogs a lot) would be very welcome for a power user. Afterall, I browse the internet with noscript, with a very short whitelist. If something requires javascript and I want to use it, I'll let it run when I want to, but not other times. A similar approach to internet connectivity in mobile apps would be very welcome. Even if it's not most convenient. I like to be in control, especially where sharing my private data with 3rd parties is concerned.

mornfall ( 2014-12-10 22:20:17 +0200 )edit

@alci: Then initially don't grant the permission, and let the app deal with the error when it tries to use it. No need to reject the app (unless it refuses to work in absence of things it should not need) Of course "at install time" should not be the only way to set permissions; one should be able to edit permissions in the same way as one can update an app. But all this belongs in the installer, and not when the app is run. And it doesn't belong into a particular component (e.g. ConnMan)

dthierbach ( 2014-12-11 16:38:28 +0200 )edit
Login/Signup to Answer

Question tools



Asked: 2014-12-10 18:02:12 +0200

Seen: 448 times

Last updated: Dec 10 '14