I confess that I come from the happy world of unix computers, and am used to the concept of user accounts and hence group gids and userids uids. For the occasional usage of an untrusted app (i.e. whatsapp/facebook) I have created another user profile for many reasons, but mostly because I wanted to reduce any potential access whatsapp/facebook might gain with regards to my main account.

Now the strange thing is that to the best of my understanding the protection mechanism of AOSP, relies on assigning a actually user ids to individual apps, as with those uid, the apps can be limited using that the underlying linux kernel provides Unix Discretionary Access Controls (i.e. file accesss dependent on uid and gid).

My question is if I am misleading myself that AOSP provides any stronger protection with regards to multi-users (in between the accounts) than it does with regards to the various apps to each other?



Being protected has a very vast meanings, varying for persons and situations. Comparing Android with *NIX systems, the former offers more isolation between apps and a more fine-grained control over permissions. The demand and reason are obvious; a phone is a 24/7 inevitable assistant as well as a perfect spy equipped with all necessary hardware tools, and it's easy to implement a more restrictive environment on a less customizable device. On PC, user is trusting all the processes / apps running under same UID (usually a human user) (1). On Android it's not the case, every app is a different user to have possibly minimum influence on the other apps. A PC user can easily get superuser / administrator rights, an Android user can't (2). Traditional *NIX DAC dates back to the early days of personal computing, when the isolation was only focused between users (UID's/GID's), not between processes / apps (there were no closed-source paid apps in stores from unknown developers; not much personal data to be protected from malicious processes; no user profiling, targeted advertisement, trackers, analytics, ransomware and so on).

DAC was later found insufficient particularly with internet revolution, hence superuser privileges were divided into capabilities and new sandboxing mechanisms were introduced at kernel level, including MAC and namespaces. Android makes use all of them more or less, they control which resources a process can access on device. Also, cgroups control how much resources a process can use. But even then, these security mechanisms weren't enough to minutely lock-down the apps, so a number of controls are handled within Android's own framework (in userspace). Android's system_server has more services running inside it than native services. When I say "mechanisms weren't enough", concern is not only to design an ecosystem to protect user's privacy / security, but also to protect Google's business model as well as of app developers.

It should also be noted that there is no standardization in Android (rather in embedded) world unlike PC's. Android uses a modified Linux kernel, which doesn't fully handle hardware in kernel space, instead relies on a number of userspace closed source processes from SoC / OEM vendors (3), which interact with other processes and hardware drivers using Android's specific binder / HAL mechanism. So *NIX DAC, which is heavily based on everything is a file philosophy, doesn't seem to work very far. A hardware device is no more a file in /dev which can be accessed by simply adding the app process to some supplementary group.
But yes, taking advantage of Linux kernel's DAC where possible, apps' internet connectivity is controlled by adding them to a special supplementary group 3003. See: How Android's permissions mapping with UIDs/GIDs works?


Coming to user's granular control over security / privacy on Android device, a few things one can be concerned about are who can:

  • Access personal data (pictures, documents, videos, backups etc.)
  • Get accounts information (added by apps including Google)
  • Get data from content providers:
    • Contacts (read/write)
    • Call log (read/write)
    • Messages (read/write)
  • Read user / device identifiers
  • Read usage statistics
  • Find installed apps
  • Access camera, record audio/video
  • Make calls, send messages
  • Get internet connectivity
  • Get location
  • Run in background

And so on.


Apps' access to most of these resources is either controlled by Android's manifest permissions or user has no control over them. For instance you can't restrict an apps access to internet without using some third party firewall. Every app which requests for android.permission.INTERNET is granted at installation time, you can't remove its supplementary group AID_INET: 3003. Similarly android.permission.READ_CONTACTS and android.permission.GET_ACCOUNTS are controlled with same toggle switch in GUI. And you can't deny an app running in background unless you use Android's hidden permissions manager: AppOps. But that's not enough. If you want more fine-grained control over permissions e.g. revoking an app's ability to getInstalledApplications, you need some heavy framework modifier like Xposed and XPrivacy.

Every app is assigned a unique UID/GID at installation time and it runs inside its own stance of Virtual Machine, forked by zygote. DAC enforced to filesystems, apps are bound to access only their own directories, particularly on internal storage (/data/user/<UserId>/<pkg_name>), private/public external storage (/data/media/<UserId>) and procfs (/proc/self/ etc.).

DAC sandboxing is also supplemented by MAC, e.g. SELinux policy won't allow apps to read /proc/stat and rootfs (/) (but allow them to read other app's data directory (4) ;). On the other hand /data/misc/profiles/cur/<UserId>/<pkg_name> is allowed by DAC but restricted by SELinux.


An XYZ app in primary user account with UID/GID 10500 can access it's private data/settings/databases in /data/user/0/<com.xyz> but not in secondary user account because /data/user/xx/<com.xyz> has UID/GID owner xx10500 where xx is UserID. How DAC governs access to /sdcard (external storage) is explained in What is the “u#_everybody” UID?

Basic sandboxing isolation exists between apps whether those are from same or different users. But a notable additional isolation between apps of different user accounts / profiles is the separate shared storage (i.e. /sdcard), which is a benefit obviously if you don't trust the app. It's because an app has access either only to its private directories, or to whole external storage. This problem of too open public files is being controlled through Android Q's privacy change: Scoped Storage.

This isolation between apps of different user accounts / profiles also exists at framework level. For instance in our above example, getInstalledApplications returns a list of all application packages that are installed for the current user only. So an app won't be able to find out what apps you have installed on other user account / profile.

Since the installed apps' data is isolated, the stock Android's content providers (which are also system apps) are also isolated. So the contacts, call logs, calendars, messages, media (list of files on external storage) etc. aren't shared among users.

Other things which are isolated between users (not necessarily enforced by DAC/MAC):

  • User/app settings which are subject to FDE, FBE and password authentications (/data/user_de/<UserId>/<pkg_name>, /data/misc/keystore/user_<UserId>, /data/misc/gatekeeper/<UserId> etc.) (5, 6)
  • Apps' usage stats (/data/system/usagestats/<UserId>)
  • System-wide accounts and settings, not all (/data/system/users/<UserId>)
  • Custom CA certificates (/data/misc/user/<UserId>)
  • Profile data (/data/misc/profiles/cur/<UserId>)

So in Android world unlike PC's, everything isn't governed by uid's/gid's, for a large part we are at the mercy of Android's core framework. But isolation between multiple users does exist, however it depends on what you want to protect from apps.


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.