per-app network access (and data roaming) control
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...)
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 )editIt 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