Permissions and apps confinement
Miguel Menéndez Carrión
In Ubuntu Touch we can use various types of applications. For instance, there are Web applications which function just like an isolated browser tab. They allow you to have a custom icon in the application Launcher, for quick access to specific web pages. For example, we can have a web application for accessing InnerZaurus. Web applications have, by definition, the most limited permissions. Another type are the native applications. With these we have more freedom to interact with the device.


The application defines the permissions it needs and if those are authorized by the user it is installed on the device. It is here where differences appear when compared with other mobile operating systems. In Ubuntu Touch we not only have permissions, we also have confinement by default. A confined application can only access the data in its own configuration folder. An application cannot usually access folders, data from other applications, external items such as the SD card etc. It is ‘sand-boxed’. This approach to security allows us to increase user safety, even if a malicious application slips through.

Introduction

On a Desktop the application permissions are much simpler and applications can access many folders on the computer. An installed application has the same access permissions as the user. It could be the case that a malicious application is able to access sensitive user data such as the contact list and then sends that information to the app creator. If such behavior were possible on Ubuntu Touch we would soon have an even bigger problem. A malicious application could not only access the call list or the contacts file but it could endanger the stability of the whole phone system. To avoid such problems we have two levels of security. The first is the permissions and the second is confinement of the applications. Each element complements the other to improve user safety and phone OS stability. As a user you could choose to always use apps without confinement and with all permissions automatically granted, although doing that would (intentionally) be a bit complicated. If you did that and then had any security problems the responsibility would be entirely yours.

Confined applications

A confined application can only access to its own configuration folder. As a result, it will not matter that we have a rogue application because it will not be able to cause problems for the user. Confined applications are published directly into the OpenStore and may be either native or Web applications. Let us talk a little about the navigation map app uNav (developed by our Marcos Costales who is currently working on the uNav version 3. update). If we check the OpenStore uNav app record and description we can see the list of resource access permissions. The first important point to check is the color of the "lock" label. If it is green, it means that the app is confined. It can only access its own configuration folder and the resources in the list of permissions.

UNav permissions



uNav can by default access sounds, keep the screen on or use the location (by GPS) of the phone. These are the normal expected permissions for a navigation map app. Map information can be downloaded in real time to internal memory but it cannot, with current permissions, be saved to the SD card. Is that a limitation or an app bug? No, it is not a bug. As we have seen before, confined applications have limited resource access. There are however OpenStore apps that can access the SD card. So how do they do that?

Unconfined applications

An example of an unconfined application is the Camera application. If we repeat the same steps that we took with uNav we will see following. The lock label has changed from green to red. Does that mean that we are facing a dangerous application that we must avoid? Obviously not. An app that is not confined can still have permissions in the normal way, which will appear in black. If they are considered «dangerous» permissions, they will appear instead in red. In GNU / Linux there is a convention of having normal users and admins. As an admin user we can access all of the software resources. In Ubuntu Touch something very similar happens but with even greater protections built in.

Camera app permissions:



When an application is not confined, it means that it has at least one «admin» permission. Those permissions which appear in red are the ones that use «admin» permissions. The Camera app can access device drivers and users’ images and videos. But, it cannot, for example, access the user’s contacts or calendar. In some cases to ensure the correct functioning of an app there have to be fewer restrictions in place. Therefore for security reasons all applications that are not confined are reviewed manually and they are not published straight to the OpenStore. They are vetted before they are published.

UNav permissions



In Ubuntu Touch we do have one obvious application that has full access to the system - that application being OpenStore. As in the previous case we will see a red lock label, indicating an application which is not confined. The permissions are very direct: Networks and full access to the system. This is of course the app which installs and uninstalls to your system, so it needs to have complete freedom to modify.


Permissions

Permissions are applied as a second layer of security, after the sandboxing which is designed into the system. An application should only be granted the minimum permissions necessary for it to work. This is dramatically different from the situation on Android, where we can find simple flashlight applications (which turn on the camera’s LED) that expect to access every part of the system by default, just like the user. Why does a flashlight need your contacts and messages?? In Ubuntu Touch,  an app cannot go outside the permissions that the developer defined and has had approved. For example, an app cannot access your data connection if it lacks that permission, so it cannot ‘call home’. Before installing an app, have a look at what it is allowed to do. Since the OpenStore is a small store, it is pretty easy to keep it clear of weird apps.

As it is the app developer who defines the app permissions, the only way to modify them is to have the source code of the app. It is not possible to modify the permissions of an app that has already been distributed as a click package. As a rule, you should only need to install applications from the OpenStore, unless you are helping to test a beta. That reliance on a moderated store is common to other mobile operating systems.




Conclusions

So, applications have two layers of security in Ubuntu Touch. On the one hand we have confinement, which prevents the application from straying into unnecessary areas and accessing resources such as user data or the memory card. On the other hand we have permissions. These define what each individual application can do, whether checking the GPS, modifying sound output, etc. If an application tries to access the camera and does not have that permission specified, it will not be able to do so.

Sometimes we need to use apps which are unconfined. It is important to be careful with these and you should only download them from the OpenStore. If you don’t, you could install a dangerous app to the device and run into problems. Using a little common sense is enough. If you have any detailed questions which are not covered here, you are welcome to ask in an appropriate UBports group on Telegram or Matrix.


References

Credits

  • Writer: Miguel Menéndez Carrión
  • English translator: Milan Korecky
  • English translator: Lionelb
Ubuntu Touch Q&A 82
VOLTE and OTA-13 news