PRIVACY: ANDROID VS. *NIX:
PROTECTION:
Being protected has a very vast meaning, varying for persons and situations. Comparing Android with *NIX systems, admittedly the former offers more isolation between apps and a more fine-grained control over permissions. Quick examples:
- 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 other apps.
- A PC user can easily get superuser / administrator rights, an Android user cannot (2).
The demand and reason are obvious:
- Privacy matters more because a phone is a
24/7 inevitable assistant as well as a perfect spy equipped with all necessary hardware tools.
- And the reason is that it's easy to implement a more restrictive environment on a less customizable device.
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. Because 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.
SECURITY MECHANISMS:
*NIX DAC was 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 of 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.
PC VS. ANDROID:
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-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 simply a file in /dev which can be accessed by adding the app process to some supplementary group, there are layers of APIs and IPCs involved (Java and native).
However Android does take advantage of Linux kernel's robust frameworks e.g. DAC. Apps' internet connectivity is controlled by adding them to a special supplementary group 3003. See: How Android's permissions mapping with UIDs/GIDs works?
WHAT SHOULD BE PROTECTED ON ANDROID:
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 read/write access to data from content providers like:
- Contacts
- Call log
- Messages
- Read user / device identifiers (MAC address, IMEI, Android ID etc.)
- Read usage statistics
- Find installed apps
- Access camera, record audio/video
- Make calls, send messages
- Get internet connectivity
- Get device location
- Run in background (e.g. surveillance or tracking apps)
And so on.
APP PERMISSIONS AND SANDBOXING:
Android divides its protected APIs in different Protection Levels. Apps' access to most of the above resources is either controlled by manifest permissions or user has no control over them.
- For instance you can't restrict an app's access to internet without using some third party firewall. Every app which requests for
INTERNET permission is granted at installation time, you can't remove its supplementary group AID_INET (3003).
- Similarly
READ_CONTACTS and GET_ACCOUNTS permissions belong to same group and are controlled with same toggle switch on GUI.
- And you can't deny an app running in background unless you use Android's hidden permissions manager: AppOps.
- And that's not the end. 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.
MULTIPLE USERS ISOLATION:
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 controls 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 Java 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>)
- ART profiles data (
/data/misc/profiles/cur/<UserId>)
CONCLUSION:
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.
REFERENCE:
