PRIVACY: ANDROID VS. *NIX:
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
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?
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 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.
APP PERMISSIONS AND SANDBOXING:
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.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 (
DAC sandboxing is also supplemented by MAC, e.g. SELinux policy won't allow apps to read
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
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
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/misc/gatekeeper/<UserId> etc.) (5, 6)
- Apps' usage stats (
- System-wide accounts and settings, not all (
- Custom CA certificates (
- Profile data (
So in Android world unlike PC's, everything isn't governed by
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.