Root on Android — Part 1 — The builds and SuperUser

Introduction:

While researching for public research on this topic, I found a lot of very disparate resources that talk about root but none of them were consolidated. I’ll try to illustrate how root on android works. Before we get into the details, we must understand some underlying basics.

The Builds:

AOSP (Android Open Source Project) comes with 3 specific make configurations viz:

userdebug:

• This is the build that’s primarily used for developing Android.
• This build comes with su binary and adb enabled by default.
• The su binary in this build is only accessible by certain uid (More on this later)
• SELinux can be disabled in this build.
• Build also comes with avc_denied logs

user:

• This is the default build that’s flashed into most retail devices aka production build
• No su binary.
• SELinux can’t be disabled
• adb is disabled by default
• build.prop is tightened (I intend to cover the importance of this file in a later post)

eng:

• This is a hybrid of user and user debug but is more closely similar to user build
• ro.debuggable is set as 1 which means adb can run as uid:root
• Debug logs are still available
• And no su binary

SU in AOSP:

Unlike regular Linux where sudo relies on a sudoers file to control who can invoke su, Android’s sudoer’s equivalent is specified in the filesystem.h (Older version of this used to specify permission based on their location in the file system). All sudo/su calls (used interchangeably) is verified through the compiled version of this file.

After the introduction of SELinux subsequent su calls are verified through a combination of filesystem configs and SELinux domain rules (Git logs here shows the evolution of restrictive SU)

SU binary also performs a check to manually check if the current UID is either AID_ROOT (uid:0) or AID_SHELL (typically uid:2000)

From Android 4.3 onwards, /system is mounted as nosuid. We’ll discuss the implications of this in the next post.

Next post:

In the next post, I’ll discuss the community’s approach to implementing SU binary and how it has evolved with changes to AOSP.