Android, as we all know is based, on top of Linux. Whenever you install an Android app, you are asked to grant certain permissions, ranging from access to gallery, contacts, call logs, camera, location, microphone to body sensors etc. However, have you wondered how these permissions are actually understood and enforced at the system's level? Every app has it's own set of requested permissions so how are these permissions assigned to the app. In Android, app is nothing but a process. According to Linux world definition: "A is a program in execution, and each process has its own address space, which comprises the memory locations that the process is allowed to access. A process has one or more of execution, which are sequences of executable instructions: a process has just one thread, whereas a process has more than one thread. process threads single-threaded multi-threaded Threads within a process share various resources, in particular, address space. Accordingly, threads within a process can communicate straightforwardly through shared memory. Of interest here is that different processes, by default, do share memory." not (Source: ) https://opensource.com/article/19/4/interprocess-communication-linux-storage This implies that whenever an app is launched, a process should be forked (from Zygote) with a certain set of permissions and the same shall be abided through while communicating to other apps (processes) through Inter Process Communication (IPC, which is facilitated through Binder in Android, more about it in some other post). Makes sense? Now having set this intent, let's reverse our point of view and see what happens when the app gets installed first. Heard of Package Manager? As per official Android documentation, "It is a class for retrieving various kinds of information related to the application packages that are currently installed on the device." Whenever you install an app, Package Manager parse the package(APK) file and display confirmation dialog box. When user press OK button, Package Manager call method named "installPackage" Somewhat like this happens,  in Package Manager Service. Add a package to the queue for the installation process Determine the appropriate location of the package installation Determine installation Install / Update new A copy of the apk file to a given directory Determine the UID of the app Request to installd daemon process Create the application directory and set permissions Extraction of dex code to the cache directory To reflect and packages.list / system / data / packages.xml the latest status Broadcast to the system along with the name of the effect of the installation is complete package  Intent.ACTION_PACKAGE_ADDED: If the new ( Intent.ACTION_PACKAGE_REPLACED): the case of an update Permissions are assigned to each application (as identified by a unique ) at install time by the system service. The package manager maintains a central database of installed packages, both preinstalled and user-installed, with information about the install path, version, signing certificate, and assigned permissions of each package, as well as a list of all permissions defined on a device. package name package manager This package database is stored in the XML file , which is updated each time an application is installed, updated, or uninstalled. /data/system/packages.xml Whether a permission is granted or not depends on its protection level which ranges from normal, dangerous, signature, signatureOrSystem. Permissions are enforced at various layers in Android. Higher-level components such as applications and system services query the package manager to determine which permissions have been assigned to an application and decide whether to grant access. Lower-level components like native daemons typically do not have access to the package manager and rely on the UID, GID, and supplementary GIDs assigned to a process in order to determine which privileges to grant it. Access to system resources like device files, Unix domain sockets (local sockets), and network sockets is regulated by the kernel based on the owner and access mode of the target resource and the UID and GIDs of the accessing process. Remember GIDs from Linux world? Here's a summary: Every file in Unix has the following attributes − − The owner's permissions determine what actions the owner of the file can perform on the file. Owner permissions − The group's permissions determine what actions a user, who is a member of the group that a file belongs to, can perform on the file. [GIDs] Group permissions − The permissions for others indicate what action all other users can perform on the file. Other (world) permissions More here: https://www.digitalocean.com/community/tutorials/an-introduction-to-linux-permissions When the application is started, the process’s UID and GID are set to the application UID assigned by the installer (the package manager service). If additional permissions have been assigned to the application, they are mapped to GIDs and assigned as supplementary GIDs to the process.Permission to GID mappings for built-in permissions are defined in the file. /etc/permission/ platform.xml Tadaaaaa, here it is: There's another interesting file which is android_filesystem_config.h Android does not have an file, so the mapping from group names to GIDs is static and defined in this header file. It defines the owner, access mode, and associated capabilities (for executables) of core Android system directories and files. (We should dig into this file separately someday) /etc/group So so so, we know what happens when an app is installed, where are the permissions saved and how are they mapped to specific GIDs (in case of predefined permissions), but how are they enforced? What actually happens when you launch the app i.e a process gets spawned? Have a look at this code snippet: As shown here, the child process first sets its supplementary GIDs (corresponding to permissions) using setgroups(), called by setgroupsIntarray() at ➊. Next, it sets resource limits using setrlimit(), called by setrlimitsFromArray() at ➋, then sets the real, effective, and saved user and group IDs using setresgid() ➌ and setresuid() ➍ The child process is able to change its resource limits and all process attributes because it initially executes as root, just like its parent process, . zygote After the new process attributes are set, the child process executes with the assigned UIDs and GIDs and cannot go back to executing as root because the saved user ID is not 0. After setting the UIDs and GIDs, the process sets its capabilities using capset(), called from setCapabilities() ➎. Then, it sets its scheduling policy by adding itself to one of the predefined control groups ➏. Hence, the kernel and system daemons use these process identifiers to decide whether to grant access to a particular system resource or function. Access to regular files, device nodes, and local sockets is regulated just as it is in any Linux system. One Android-specific addition is requiring processes that want to create network sockets to belong to the group is an explicit permission in Android, remember?) inet (INTERNET While Binder is the preferred IPC mechanism in Android, lower-level native daemons often use Unix domain sockets (local sockets) for IPC. Because Unix domain sockets are represented as nodes on the filesystem, standard filesystem permission can be used to control access. References Android Security Internals by Nikolay Elenkov For more such discussions let's connect on Twitter @4ditiBhatnagar Previously published at https://www.digitised.in/post/how-are-android-permissions-mapped-at-kernel-s-level

Target

Twitter

Did VOLD-emort Just Kill My App?

How To Check Whether The Mobile App On Your Phone is Authentic or Not

Book a call

Nominated for 2022 - HackerNoon Contributor of the Year - Cybersecurity

Too Long; Didn't Read

Make resilience your competitive advantage

How Android Permissions Mapped at Kernel's Level

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Is the Weakest Link in Cybersecurity Becoming Even Weaker?

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Is the Weakest Link in Cybersecurity Becoming Even Weaker?

Java bits: 0xFF and 0xFFL

10 Things You Didn't Know You Could Do With Google Keep

10 Things to check on Android code reviews

10 Mistakes In Mobile App Development That Make You Look Dumb

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps