Apps are the New Users

Some facilities provided by mature multi-user operating systems appear arcane today. Administrators of computers running Mac OS X or Linux can see users logged-in from remote terminals, they can specify limits on the disk space one can use, and they can run accounting statistics to see how much CPU time or disk I/O a user has consumed over a month. These operating systems also offer facilities to group users together, to specify various protection levels for each user's files, and to prescribe which commands a user can run.

Interestingly, three developments allow us to repurpose the traditional user management of Unix-like systems to increase the security and robustness of software run by millions. First, devices like smartphones and tablets make our computers more and more personal, thus obviating the need for old-style multi-user management. In addition, most such devices are still based on multi-user operating systems: Android's kernel comes from Linux while Apple's iOS is derived from Darwin, another Unix-like operating system. Furthermore, these devices have introduced the concept of "apps": hundreds of thousands of powerful, self-contained, third-party applications that are easily installed, often on a whim. Given that a device's owner has little knowledge and direct control of how an app will behave, it seems practical to isolate those apps from the phone's core functionality and from each other by using for this purpose the operating system's concept of a user.

Applications may need to do many things, from making a call, to taking a picture, to vibrating the phone, to obtaining its GPS location. Android specifies 122 separate permissions. Building a software stack for managing these permissions from scratch sounds like a tall order. Therefore, leveraging Unix's existing separation between users to isolate apps is a reasonable choice, and it seems that this is the one taken by Android.

Mapping phone resources to app permissions through the Unix security model is temptingly straightforward. Each permission is associated with a group. Files or devices that are required to exercise the rights of that permission are made to belong to that group and given the appropriate group read or write permission. (Remember that on Unix devices appear in the file name space.) If a file or device is associated with more than one permission, distinct names can be linked to it through Unix's hard links, each one belonging to the corresponding group. Finally, each app is made to belong to the groups associated with the permissions it requires.

Here is a hypothetical example. Assume a phone has an SMS transmission and a GPS location facility. The corresponding files (a named pipe to the SMS transmission daemon and a character device linked to the GPS) are made to belong to corresponding groups and are given the appropriate permissions.

prw--w-----  1 root  sendsms       0,  30 Nov  1 17:59 sms-outbox
crw-r------  1 root  location      0,  31 Nov  1 17:59 gps

If an application, say, sendmylocation, requires access to these permissions, this is simply specified in the /etc/group file.

sendsms:*:62:app1,app2,sendmylocation
location:*:94:app5,app8,app2,sendmylocation,app9

All the rest is handled by a security model and a kernel that has been used for years for this purpose.

This user-per-app model can also be used through Unix's quota mechanism to specify file space limits for each app and also for process accounting. This allows a user to set the maximum amount of disk space that an app can use, and see how much CPU time the app has used over a period.

Legacy support for process accounting can however only take us this far. For a modern device the kernel should be modified to tally up more accounting data. This should include network I/O per interface (so that an application's WiFi usage can be seen separately from its, potentially expensive, 3G data requirements) and the use of power-draining devices (so that a user can monitor an app's use of battery power). Furthermore, because many apps never terminate, there should be a library to consolidate a running process's resource usage with its corresponding accounting records.

Comments   Toot! Tweet Share