Chapter 1. Linux Access Controls

Android is an operating system composed of two distinct components. The first component is a forked mainline Linux kernel and shares almost everything in common with Linux. The second component, which will be discussed later, is the user space portion, which is very custom and Android specific. Since the Linux kernel underpins this system and is responsible for the majority of access control decisions, it is the logical place to begin a detailed look at Android.

In this chapter we will:

Linux's default and familiar access control mechanism is called Discretionary Access Control (DAC). This is just a term that means permissions regarding access to an object are at the discretion of its creator/owner.

In Linux, when a process invokes most system calls, a permission check is performed. As an example, a process wishing to open a file would invoke the open() syscall. When this syscall is invoked, a context switch is performed, and the operating system code is executed. The OS has the ability to determine whether a file descriptor should be returned to the requesting process or not. During this decision-making process, the OS checks the access permissions of both the requesting process and the target file it wishes to obtain the file descriptor to. Either the file descriptor or EPERM is returned, dependent on whether the permission checks pass or fail respectively.

Linux maintains data structures in the kernel for managing these permission fields, which are accessible from user space, and ones that should be familiar to Linux and *NIX users alike. The first set of access control metadata belongs to the process, and forms a portion of its credential set. The common credentials are user and group. In general, we use the term group to mean both primary group and possible secondary group(s). You can view these permissions by running the ps command:

$ ps -eo pid,comm,user,group,supgrp
PID COMMAND         USER     GROUP    SUPGRP
1 init            root     root     -
...
 2993 system-service- root     root     root 
 3276 chromium-browse bookuser sudo fuse bookuser 
...

As you can see, we have processes running as the users root and bookuser. You can also see that their primary group is only one part of the equation. Processes also have a secondary set of groups called supplementary groups. This set might be empty, indicated by the dash in the SUPGRP field.

The file we wish to open, referred to as the target object, target, or object also maintains a set of permissions. The object maintains USER and GROUP, as well as a set of permission bits. In the context of the target object, USER can be referred to as owner or creator.

$ ls -la
total 296
drwxr-xr-x 38 bookuser bookuser  4096 Aug 23 11:08 .
drwxr-xr-x  3 root     root      4096 Jun  8 18:50 ..
-rw-rw-r--  1 bookuser bookuser   116 Jul 22 13:13 a.c
drwxrwxr-x  4 bookuser bookuser  4096 Aug  4 16:20 .android
-rw-rw-r--  1 bookuser bookuser   130 Jun 19 17:51 .apport-ignore.xml
-rw-rw-r--  1 bookuser bookuser   365 Jun 23 19:44 hello.txt
-rw-------  1 bookuser bookuser 19276 Aug  4 16:36 .bash_history
...

If we look at the preceding command's output, we can see that hello.txt has a USER of bookuser and GROUP as bookuser. We can also see the permission bits or flags on the left-hand side of the output. There are seven fields to consider as well. Each empty field is denoted with a dash. When printed with ls, the first fields can get convoluted by semantics. For this reason, let's use stat to investigate the file permissions:

$ stat hello.txt
  File: `hello.txt'
  Size: 365         Blocks: 8          IO Block: 4096   regular file
Device: 801h/2049d  Inode: 1587858     Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/bookuser)   Gid: ( 1000/bookuser)
Access: 2014-08-04 15:53:01.951024557 -0700
Modify: 2014-06-23 19:44:14.308741592 -0700
Change: 2014-06-23 19:44:14.308741592 -0700
 Birth: -

The first access line is the most compelling. It contains all the important information for the access controls. The second line is just a timestamp letting us know when the file was last accessed. As we can see, USER or UID of the object is bookuser, and GROUP is bookuser as well. The permission flags, (0664/-rw-rw-r--), identify the two ways that permission flags are represented. The first, the octal form 0664, condenses each three-flag field into one of the three base-8 (octal) digits. The second is the friendly form, -rw-rw-r--, equivalent to the octal form but easier to interpret visually. In either case, we can see the leftmost field is 0, and the rest of our discussions will ignore it. That field is for setuid and setgid capabilities, which is not important for this discussion. If we convert the remaining octal digits, 664, to binary, we get 110 110 100. This binary representation directly relates to the friendly form. Each triple maps to read, write, and execute permissions. Often you will see this permission triple represented as RWX. The first triple are the permissions given to USER, the second are the permissions given to GROUP, and the third is what is given to OTHERS. Translating to conventional English would yield, "The user, bookuser, has permission to read from and write to hello.txt. The group, bookuser, has permission to read from and write to hello.txt, and everyone else has permission only to read from hello.txt." Let's test this with some real-world examples.