Doubt on Android permissions mapping with UIDs/GIDs

Question

Reading the book: Android Security Internals I'm reading at Chapter 2 - Permission Management paragraph that permissions are assigned to application at install time by the packet manager with a mapping like Apk's UID <-> Permissions.

Later in the book (Permission Assignment - Permissions and Process Attributes paragraph) I read that

If additional permissions have been assigned to the application, they are mapped to GIDs and assigned as supplementary GIDs to the process.

And, since android.permission.INTERNET permission is associated with inet GID:

any process for an app that has been granted the INTERNET permission is associated with the supplementary GID correspond- ing to the inet group

But I was asking me if this is always necessary.

Imagining a case where you install APK X declaring android.permission.INTERNET permission in AndroidManifest.xml, since mapping of permissions with UIDs is done at install time, PacketManager should be able to map the permission directly with the APK's UID instead of adding inet GID to your APK package.. So I'm wondering why it has to be that:

any process for an app that has been granted the INTERNET permission is associated with the supplementary GID correspond- ing to the inet group

Anyone can clarify me this?

Answer 1

Things usually needs permission because the permission protects a shared resource. When there is shared resource in a Linux based system, that shared resource is usually assigned a name by the kernel as an object in the filesystem. For example, as regular file, Unix socket files, device files, or special files in sysfs/procfs. A lot of native system daemons in Android are represented as a socket in /dev/socket, and hardware device drivers represent themselves to userspace applications as device files. These sockets/device files are used by applications to talk with a native system daemon or a kernel driver.

The filesystem in a Linux (or any Unix-based system) is essentially a namespace that user space applications can use to refer to kernel objects, and the kernel enforces Unix file permission to control access to interact with these kernel objects. In Unix file permission, each objects in the filesystem belongs to exactly one Owner UID and Owner GID.

If you were to assign the permission object directly to the UID, then you would have needed to create one socket file for each user/application that needs to talk to the underlying shared resource. When you add more applications to the system and when the system is updated to add/remove a daemon, you'll need to recreate those socket/device files for each combination of system service and applications. This would have been clunky and error prone.

Instead, because permissions are assigned indirectly via GID, what happens is that multiple applications can all talk to the same socket file. The system daemon would only need to listen on one socket file, but only applications whose supplementary group includes the socket file's GID would be able to talk to that daemon or kernel driver. This file permission mechanism is enforced by the Linux kernel.

Note that the Android framework also contains a number of higher level permissions that are enforced by the permission system, at system applications level, rather than by the kernel. These application level permissions works differently than the kernel level permissions, they query the Android package manager and/or an application code to decide whether or not to grant permission. What's described in the previous paragraphs applies to permissions that are enforced at the kernel level, not these application level permissions.

Answer 2

mapping of permissions with UIDs is done at install time

Yes: X gets a UID u at installation time. The decision to give u the INTERNET permission is made at installation time.

PacketManager should be able to map the permission directly with the APK's UID

What do you mean by “directly”? The way a permission is mapped to a UID is done by associating the permission with a GID, and storing a database entry that lists the GIDs for each UID. So the package manager does map the permission to the installed application's UID. (Note that the UID is not part of the APK. It's assigned arbitrarily at installation time: two different Android systems won't give the same UID to the same application in general.) It does this by granting the application the GID corresponding to the requested permission.