Most elements of the hardware, or data sets shared between apps on the Android and iOS platform are controlled strongly, and only provided to apps explicitly on a need-to-know basis. This can allow the user to make sure, for example, a malicious flashlight app isn't uploading their location and contacts list.

On the desktop on Ubuntu, there are effectively two permission levels of control: user, and root. In the case of user, not much restriction is afforded. It can still connect to the internet, interface with most any hardware it likes, and read/write any files in /home/user/. This model assumes that the user is competent enough to ensure an application they are using is legitimate (which is very easy with open-source software).

So my question is, what sort of restrictions and control over an app's abilities will be in place on the mobile platform? And since it's all the same OS, how will that system overflow into the desktop? Will all programs need to be sandboxed?

I'm quite keen to know the plan :)

PS. One thing I like about the way iOS does it over Android is that many permissions must be explicitly approved by the user when it runs for the first time. The result being, if you don't want to tell the Facebook app where you are, you can just disallow it, versus on Android where you just have to uninstall the app and Get Over It™.

The system I'd like to see is it asking for permission with a "Just this once" and an "Always" option, when the app needs that permission to execute a command. Want to find yourself on the map? Ask for location permission. Just like the way some HTML5 APIs are handled.

  • 3
    I like your question. It is one of the annoying things to me that some apps in Android request too many privileges and I don't even understand what the apps need them for. Considering the early stage of the system there is not much focus on that issue yet. But it will gain more importance in the later phase.
    – NilsB
    Mar 21, 2013 at 17:32
  • 2
    While I like your question in theory, in application it means making the "pure linux on arm" part of the device go away (which in my opinion was its coolest advantage). Perhaps - read as hopefully - they will implement each app is a user similar to what services do now. Mar 24, 2013 at 22:16
  • 1
    It doesn't really mean anything about hardware access. That is managed by groups just like on pure regular linux. People forget that because their user is magically part of the audio group or a dial group for usb-ttys or whatever. Wireless access? Apps sign requests sent over dbus, problem solved. Linux permissions work. Mar 27, 2013 at 11:45
  • 1
    I'm not on the dev team, but audio devices require the user to be in the relevant group, as do tty devices, etc on vanilla ubuntu. Mar 27, 2013 at 19:15
  • 1
    At least audio devices, modems, wlan, ethernet, gpu, cpu, ram, dvd, usb, card reader, bluetooth, printers, webcams, ata, sata, esata, keyboard, mouse, touchpad and fingerprint reader access can be restricted based on groups OR/and users. Every device accessed through device node have its own grp/permission. If app uses sockets, just set groups/permissions. There's also different ways (yep, you have options too) to restrict communication between apps, services and so on (already mentioned D-Bus and other RPC-like services). Even ls could be restricted. This box has length restriction... Apr 3, 2013 at 0:14

1 Answer 1


This is being worked on as part of the Ubuntu App Developer Upload spec, in particular, the section on security.

This is still in early stages, but as an extract to the spec, and to provide some context:

Once an application is installed, AppArmor will provide a security sandbox to protect the user from malicious or simply broken code. To accomplish this, each application will need a properly constructed, and minimally permissive profile to restrict what their application can access on the local system.

Applications will be sandboxed via AppArmor, and permissions will be granted according to the app's AppArmor security profile.

  • I guess that means they get the permissions when they're installed?
    – Jonah
    Apr 11, 2013 at 16:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.