Date post: | 21-Feb-2015 |
Category: |
Documents |
Upload: | jeremy-foo |
View: | 805 times |
Download: | 1 times |
SCE10-0496
Open Source Security Issues of
the Android Platform
A Final Year Project Report
by
Jeremy Foo Jie You
for the
School of Computer Engineering
Nanyang Technological University
under the supervision of
A/P Yow Kin Choong
for the requirements of the
Degree of Bachelor of Computer Engineering
submitted
17th October 2011
Abstract
The Android platform is fast becoming the dominant mobile operating
platform in the world, having bested the iPhone in US market share and
closing steadily on worldwide share.
By its very nature of being an open source project, the Android platform not
only raises security issues through its transparency of its source code, it also
allows for more security risks because of its open nature where developers are
given free reign and also through its un-curated distribution system in the
form of the Android Marketplace.
This project seeks to analyze these security issues, quantify them and propose
a way to mitigate these risks by either preventing them or removing them.
Research is based on the Google Nexus S running Gingerbread, version 2.3.3
based on the Linux Kernel, version 2.6.35.7.
This report quantifies this effort in dealing with the possible security issues of
the Android operating system through analysis of its security architecture,
and current work done to improve security. It also documents the proposed
solution along with a proof of concept and relevant test results for verification
of the hypothesis.
Acknowledgements
For the period of my Final Year Project (August 2010 - August 2011), I would
like to thank the following whom without, all the work that I was doing will
not be possible.
• Prof Yow for this invaluable help in procurement of hardware resources
needed for the project as well as his scrutiny, advice and direction in
helping develop the overall project from its inception to its finality.
• Ted Hsiang for his initial research work on malware on the Android
Platform which helped immensely in the development of the testbed to
verify the thesis of this very project.
• Ming Jin for assisting in the actual development of the testbed application
and input of ideas.
Table of Contents
1. List of Figures 1
Abbreviations 1
3. Introduction 2
3.1 Platform versus Operating System 3
3.2 Objectives 3
3.3 Research Details 4
3.3 Tools used 5
4. The Android Platform 6
4.1 Philosophy 6
4.2 Hardware 7
4.3 Kernel 8
4.4 Operating System 9
4.5 Third Party Development 21
5. Security Audit 24
5.1 Existing Protection 25
5.2 Attack Surface 31
5.3 Chain of Trust violation through Full Access 35
5.4 Existing Security Compromises 39
5.5 Conclusion 42
6. Securing Android 43
6.1 Philosophy 43
6.2 Existing Work 47
6.3 Mandatory Access Control 49
6.4 Hardening 51
7. Proof of Concept 56
7.1 Security Enhanced Linux 57
7.2 Patching Dalvik 58
7.3 grsecurity Patches 56
7.4 Test and Audit Tool 58
8. Conclusion 59
Recommendations 61
References 62
11. Appendix 67
11.1 Android /system/bin 67
11.2 Ubuntu /bin 69
11.3 Android Filesystem Configuration Header 71
11.4 New files added to Android Kernel 75
11.5 Sample process list using ps 78
11.6 init.rc Script 80
11.7 Sample MANIFEST.MF 86
11.8 Sample CERT.SF 87
11.9 Android Application to Test Permissions and Runtime.Exec 88
11.10 Sample netstat -a output 89
1. List of Figures
Figure 4.4.1 Android Software Stack
Figure 4.4.3.1 In depth Android Software Stack
Figure 4.4.5.1 Android Startup Flow
Figure 5.1.1 Permissions Model Hierarchy
Figure 5.1.2 Android Application Installation and Permission Request
Figure 5.1.3 BlackBerry Permissions
Figure 5.3.1 Trusted Execution Path
Figure 5.3.1.1 Nexus S Low Level Bootloader
Figure 5.3.1.2 Nexus S unlock bootloader confirmation
Open source security issues of the Android Platform
1
2. Abbreviations
AOSP Android Open Source Project
ARM Advanced RISC Machines
SoC System on a Chip
IPC Inter Process Communication
NDK Native Development Kit
SDK Software Development Kit
LSB Linux Standard Base
POSIX Portable Operating System Interface for Unix
GNU GNU is Not Unix
BSD Berkeley Software Distribution
GPL GNU General Public License
LGPL GNU Lesser General Public License
EXT4 Fourth Extended File System
YAFFS Yet Another Flash File System
ROP Return Oriented Programming
OLPC One Laptop Per Child
UID Linux User ID
GID Linux Group ID
DAC Discretionary Access Control
MAC Mandatory Access Control
ABI Application Binary Interface
ADB Android Debug Bridge
JNI Java Native Interface
XSS Cross Site Scripting
DEP Data Execution Prevention
ASLR Address Space Layout Randomization
PIC/PIE Position Independent Code/Execution
NX No eXecute
Open source security issues of the Android Platform
1
3. Introduction
In the words of Google, Android was created as an alternative to Apple’s
vision of mobile devices1. The differences between either are evident in their
philosophies towards every aspect of the platform, from its distribution,
development to even how third party applications interact with the user and
the operating system.
With Android being the alternative platform, it takes the polar opposite of
Apple’s methods, opting for an open approach to almost every aspect of their
platform versus what developers famously term, Apple’s “walled garden”.
Developers are free to use any language and tools to write their applications
in. Distribution via the Android Marketplace does not require prior review
nor curation.
While it is an absolutely delightful playground for developers, some security
concerns have been raised by companies with regards to the open source
nature of the operating systems codebase. Due to the transparency of its
source code, there are fears that malicious individuals can easily examine and
find security issues that are exploitable through the very source code
powering the platform.
Extrapolating from the open source nature of the platform, further security
concerns can be raised as developers are given free reign to do almost
anything they want, short of the permissions system that Android
implements and the permissions that the user specifies at install time.
Open source security issues of the Android Platform
2
1 Clint, B. (2010, May 2). Android vp gundotra takes gloves off vs. apple at google i/o [Web log message]. Retrieved from http://www.eweek.com/c/a/Mobile-and-Wireless/Android-VP-Gundotra-Takes-Gloves-Off-Vs-Apple-at-Google-IO-455468/
The Android project page states that the platform is a privilege separated
operating system that makes use of Application Signing, sandboxing of
applications through the use of UserIDs and Groups as well as enforcement
of permissions that the user specifies at install time.
Yet in recent reports, there has been a significant rise in Android malware
while the incumbent iOS platform does not seem to have yet suffered any
such serious security compromises that does not have a prerequisite of
“jailbreaking” the phone.
3.1 Platform versus Operating System
In referring to the Android project, there are 2 distinctions that has to be
made and reinforced. Of note, when referring to the Android platform, this
has to do with the encompassing project, its operating system, its distribution
model, basically everything to do with Android.
However, when referring to the Android Operating System, this only
encompasses the software that is providing services to the platform. As such,
this covers things like the operating system kernel, the software stack, Dalvik,
etc.
3.2 Objectives
Security research is a very broad topic that covers multiple areas of computer
science that requires cross disciplinary knowledge. This report quantifies the
work done in the research and development of creating a viable modern
security environment for the Android platform.
Included in this process is an audit of the key security features of the Android
Operating System and comparisons with its rival in the form of Apple’s iOS
platform.
3
A formulation of steps needed to be taken to improve the security mechanism
on the Android platform based on the work done in this project is also
included as a proposal for the future.
All these is needed in an attempt to answer the question of security issues
with the Android operating system, open source or otherwise, and what can
be possibly done to fix them.
3.3 Research Details
The hardware device chosen for the basis of this research is the Samsung
Nexus S. It is a Google branded Android phone which has an unlock-able
bootloader that facilitates flashing of custom firmware.
Software wise, Android 2.3.x otherwise known as Gingerbread is the status
quo along with the Linux kernel in the device that runs at version 2.6.35.7.
Relevant source code and drivers are also hosted on Android’s kernel.org git
source code repository which speeds up the process research and
development on this platform without need to hunt for extraneous drivers
and files to get the operating system working.
As the project is Linux based with modifications by Google to run their own
code, much parallels can be drawn from the Linux open source project when
it comes to dealing with the Kernel. Additionally, due to Android being an
open source project and largely developer friendly, there are numerous
forums dedicated to hacking on Android devices.
Being security research poses certain problems when it comes to references,
even more so when it comes to a platform developed by the world’s largest
internet company. As such, information from any reliable source is valuable,
4
and with the information security largely based online, there is vast
knowledge base that only exist on the internet.
3.3 Tools used
• Ubuntu Linux 11.04 as the development environment for compilation
and development for the Android platform. This is the platform that Google
has chosen as their de facto environment and thus there is some sense to
use it.
• Git for version control when it comes to development work as well as
cloning code from Google’s source code repository.
• Samsung Nexus S Specific Kernel (herring) is a Samsung Nexus S
specific kernel with modules an drivers that are provided so it can be built
specifically for the device.
• Android SDK is the development environment that is used by all Android
third party application developers and includes numerous tools to help with
development on Android devices.
• Android Open Source Project (AOSP) contains all the system files and
other things needed to create custom firmware that can be flashed onto
devices.
5
4. The Android Platform
The operating environment needs to be throughly understood before even
starting on a security audit. This includes the processes that drive the design
and development of the system, the way the software interfaces with the
hardware, down to the philosophy behind the choices made.
Originally Android was an operating system developed by Android Inc.
founded by former Danger co-founder, Andy Rubin. Eventually, Google
acquired2 the company and prepared to enter the mobile phone market with
initiatives like the Open Handset Alliance to find manufacturing partners.
As of late, Android is the lead market share holder when it comes to the
platform with iOS trailing in second place. This is largely attributed to the
numerous manufacturing licensees that they have and the general open
source nature of the project.
4.1 Philosophy
In the grand scheme of things, Google acts as the Operating System licensor
that provides the license to use the Android Operating System as well as
support for manufacturers to implement it on their devices. Google has never
seen themselves as a hardware manufacturer even putting out a call for bids3
when it comes to the manufacture of their own Google branded Nexus
phones.
Open source security issues of the Android Platform
6
2 Elgin , B. (2005, August 15). Google buys android for its mobile arsenal. Bloomberg Businessweek. Retrieved from http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm
3 Perez, S. (2011, August 15). Google / motorola deal doesn’t guarantee a “nexus droid” [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/google-motorola-deal-doesnt-guarantee-a-nexus-droid/
Even though the operating system is covered under an open source license,
use of the Google brand along with other applications that tie in with Google
services are used to enforce compliance with Google specifications for
manufacturers. This is done through a compatibility test suite, that
manufacturers have to pass4 in order to have Google allow their applications
to work on whatever device that is being tested on the test suite. Most notable
of all is the exclusion of access to the Android Marketplace should devices not
meet the compatibility definitions.
The entire Android platform contains components that are free, open source
as well proprietary. Google has made efforts to stay away from free software
licenses like GPL and LGPL as far as possible going as far as implementing
their own versions of currently existing libraries. Notable amongst these are
the Dalvik runtime as well as Bionic, a BSD licensed version of libc5.
Prior to version 3.0 of the platform the entire project was licensed under
Apache License 2.0, however versions since 3.0 have been under a closed
source model. Patches to the Linux kernel for Android still adhere to the GPL
2.0 license model.
4.2 Hardware
Google IO 2011 was where the grand vision for putting Android in as many
devices as possible was unveiled. Exercise machines, lightbulbs, media
systems were just some of the examples that the presenters were raving
7
4 Patel, N. (2011, May 12). How google controls android: digging deep into the skyhook filings [Web log message]. Retrieved from http://thisismynext.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/
5 Paul, R. (2009, February 23). Dream(sheep ): a developer's introduction to google android [Web log message]. Retrieved from http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars
about6. However, the most popular devices that run Android to this day are
still mobile phones, and only recently, tablet form factor computing devices.
Being a Linux based operating system, Android is capable of running on
almost any platform that Linux supports. However, because of Google’s
concentration on mobile devices, it is highly optimized and will officially only
run on devices that have an ARM based processor7. There have been efforts to
port Android to x86 based processors but is and remains an unofficial fork of
the Android project.
Similar to any other computer system, the core components of an Android
device consist of a central processing unit which is ARM based, RAM as well
as secondary storage for the operating system. Devices also contain various
IO systems like the screen, sensors and wireless chipsets to make the device
full featured.
4.3 Kernel
In order to get Linux running according to Google’s requirements, the Linux
kernel has been forked at the 2.6.x branch and patches have been applied to
it. These patches have focus on mobile devices evident by the largest patch to
the kernel being the power management concept of wakelocks.
There has been efforts to merge the changes to the Android Linux kernel back
to the mainline but has meet with various technical challenges. These in
particular have to do with the mentioned wakelocks8 power management
8
6 GoogleDevelopers. (Producer). (2011). Google i/o 2011: keynote day one. [Web Video]. Retrieved from http://www.youtube.com/watch?v=OxzucwjFEEs
7 Vassillis, A. (2011, June 02). From zero to boot: porting android to your arm platform [Web log message]. Retrieved from http://blogs.arm.com/software-enablement/498-from-zero-to-boot-porting-android-to-your-arm-platform/
8 Corbet, J. (2009, February 10). Wakelocks and the embedded problem [Web log message]. Retrieved from http://lwn.net/Articles/318611/
locking mechanism 9, a different IPC mechanism as well as various changes to
the user/kernel space boundary.
To further complicate things, the way the source code to the Android project
is controlled by Google, allows only employees to contribute such changes to
the mainline kernel10.
Beyond the philosophical idea behind the kernel for Android, a diff of the
Samsung 2.6.35.7 Linux Kernel and the stable mainline kernel produces a diff
file of about 10MB of differences. When diff was told to ignore new files and
just concentrate on changes within the kernel sources, a much smaller 722KB
diff was produced.
On closer examination of all the number of new files11 added to the Nexus S
Linux Kernel, majority of code additions were related to platform and
hardware specific drivers for the Nexus S. These are commonly added to the
drivers directory as well as the arch directory but do not preclude the other
directories and does indicate heavy involvement from OEM partners to write
kernel code that interfaces with hardware. From code analysis, majority of
non platform specific code changes were largely made in the power directory
to support the wakelocks mechanism and additional driver support for the
binder IPC mechanism in drivers/staging/android.
4.4 Operating System
Android as an operating system can be thought of as a distribution of Linux,
with its own intricacies and structure. A more accurate description according
9
9 Corbet, J. (2009, February 18). From wakelocks to a real solution [Web log message]. Retrieved from http://lwn.net/Articles/319860/
10 Kroah-Hartman, G. (2010, December 09). Android and the linux kernel community [Web log message]. Retrieved from http://www.kroah.com/log/linux/android-kernel-problems.html
11 See Appendix “New files added to Android Kernel”
to Linux Torvalds12 is that Android is essentially a fork of the Linux project
and that perhaps sometime in the future, the gap between the mainline will
merge with the Android fork.
It is however not considered a distribution of Linux in the strictest sense if
you take into account certifying it against the Linux Foundation’s Linux
Standard Base. That being said, LSB13 is a good way to help understand the
differences and the similarities between Android and regular Linux
installations on devices. The LSB exists to standardize the software system
structure of any Linux operating system and is based on a variety of open
standards like POSIX, Single Unix Specification.
Figure 4.4.1 Android Software Stack
10
12 Vaughan-Nichols, S. J. (2011, August 18). Linus torvalds on android, the linux fork [Web log message]. Retrieved from http://www.zdnet.com/blog/open-source/linus-torvalds-on-android-the-linux-fork/9426
13 Linux standard base (lsb). (2010, April 29). Retrieved from http://www.linuxfoundation.org/collaborate/workgroups/lsb
Beyond the classification of Android, it is also important to understand the
software stack that Android uses. As shown in Figure 4.4.1, the Android
software stack gives the impression that the operating system is Linux like
but does show enough differences from traditional Linux operating systems
that sets it apart.
4.4.1 File System
Prior to even diving into the file system structure that Android uses, we first
must be aware of the different types of file systems that are mounted by the
operating system. With the help of the mount tool, we are able to see an entire
listing of the different types of file systems attached.
$ mountrootfs / rootfs ro,relatime 0 0tmpfs /dev tmpfs rw,relatime,mode=755 0 0devpts /dev/pts devpts rw,relatime,mode=600 0 0proc /proc proc rw,relatime 0 0sysfs /sys sysfs rw,relatime 0 0none /acct cgroup rw,relatime,cpuacct 0 0tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0none /dev/cpuctl cgroup rw,relatime,cpu 0 0/dev/block/mtdblock4 /cache yaffs2 rw,nosuid,nodev,relatime 0 0/dev/block/mtdblock6 /efs yaffs2 rw,nosuid,nodev,relatime 0 0/dev/block/platform/s3c-sdhci.0/by-name/system /system ext4 ro,relatime,barrier=1,data=ordered 0 0/dev/block/platform/s3c-sdhci.0/by-name/userdata /data ext4 rw,nosuid,nodev,noatime,barrier=1,data=ordered 0 0/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0/dev/block/vold/179:3 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0/dev/block/vold/179:3 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0/dev/block/dm-0 /mnt/asec/com.rugbyworldcup.AndroidClient-1 vfat ro,dirsync,nosuid,nodev,relatime,uid=1000,fmask=0222,dmask=0222,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
Lines that are highlighted in bold list file system mount points that are of
particular interest. While the kernel exists within the ramdisk image on the
ROM, the /system mount point is where the actual operating system along
11
with its files reside. This is naturally mounted read only to provide for some
security.
The /data mount point directs to a location where all user generated data is
stored. This includes the applications the user downloads, the settings to the
various configurations of the device and even log files. Along with the /data
mount point, the /sdcard mount point behaves similarly with a focus of being
external storage that gets mounted if an SD Card exists.
An interesting thing to note is that the file system is generated in parts as
ramdisks and these are in turned flashed onto the ROM of devices or
packaged as a full firmware image14 that consists of the root, data and system
ramdisks as well as the kernel and other parts that make up Android.
Ramdisks are stored in the cpio15 file format and are compressed using the
GNU utility gzip prior to flashing onto device.
The file system structure roughly resembles that of any LSB certified Linux
distribution. With the exception of specially mounted directories like
/sdcard and OEM specific directories, the file structure contains the almost
ubiquitous directories like /dev, /etc, /mnt, /root and so on.
With the move to Android 2.3.x and as shown, Google has changed the file
system format in use to ext4. ext4 offered many advantages over YAFFS
which was previously used, most noticeable of all speed improvements16 as
12
14 Howto: unpack, edit, and re-pack boot images. In (2008). Retrieved from http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
15 http://www.gnu.org/software/cpio/
16 Peter. (2010, December 28). Android 2.3 gingerbread uses ext4 file system, promises better dual-core performance [Web log message]. Retrieved from http://blog.gsmarena.com/android-2-3-gingerbread-uses-ext4-file-system-promises-better-dual-core-performance/
well as improved support within the kernel as it was marked as stable under
the 2.6.28 source code repository.
While the upstream version of YAFFS has support for extended attributes17,
the version that is currently used by Android does not. Switching to ext4 lets
the Android operating system to gain that feature along with other
improvements.
Where the file system differs from LSB certified distributions is the lack of
certain POSIX shell and utilities. A directory listing of the /bin directory on a
copy of Ubuntu Linux and Android (located in /system/bin) shows a variety
of differences18, some which are platform specific but more importantly,
others which are needed comply with POSIX specifications which is a subset
of LSB certification is missing.
Workarounds by using BusyBox19 or installing applications that bundle and
install important POSIX utilities are a necessity if more in depth exploration
of the operating system is required.
4.4.2 Standard Libraries
Linux by default uses the GNU libc as the standard C library. While there is
an implementation of the standard C library for embedded linux systems, it is
also covered under a GNU public license - LGPL. In order to maintain the
GPL boundary at the kernel20, Google chose to rewrite the C standard library.
13
17 Smalley, S. (2011, May 11). Re: [android-kernel] froyo : ext4 instead of yaffs2 [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/[email protected]/msg03101.html
18 See Appendix “Android /system/bin” vs “Ubuntu /bin”
19 Common UNIX utilities in a single executable. See www.busybox.net.
20 Cheri, Y., Schaller, A., & Wilson, G. (2007). Whitepaper: open source best practice. Retrieved from http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Whitepaper-Open-Source-Best-Practice/
In addition to preventing GPL contamination of the user space by keeping the
Bionic C library under a BSD license, the rewrite also helped in letting Google
write a version of the library that was specific to the needs of Android mobile
devices.
Bionic is a small and speedy library 21 that was specifically designed for low
clock frequencies that are seen in mobile devices. It’s size is also about 50%
smaller than glibc (GNU standard C library) as it has to be loaded into each
process.
It is not a surprise then that because of its smaller size, some POSIX features
and others that are present in glibc do not exist in Bionic. These features are
also dropped because they did not have a use on Android itself.
Consequently, Android specific support for system services exist in Bionic.
In the theme of keeping standard library small, Bionic does not use the
threading API that is implemented in glibc instead, it makes the most use of
the kernel threading features22. Keeping with the theme of excluding certain
features, some threading features were also not included, for example the
support for thread cancellation.
Apart from the C Standard Library, Android does provide other compiled
libraries for use in applications. Some of the more notable libraries include
the sqlite and the OpenGL ES libraries. These libraries are commonly stored
in the /system/lib directory and are compiled to be used as shared libraries
evident by the .so extension.
14
21 Burnette, E. (2008, June 04). Patrick brady dissects android [Web log message]. Retrieved from http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584
22 Castet, M. (2008, November 06). android thread library ported to uclibc [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/[email protected]/msg02787.html
4.4.3 IPC Mechanism
The Android operating provides 3 different IPC mechanisms which are used
in different situations and work at different levels of the platform.
• Linux Kernel IPC for native applications.
• Socket/New IO (NIO) available in Java.
• Binder for access to specific system services.
• DBus daemon for use by the GPL Bluetooth subsystem (Bluez).
For all intents and purposes, the only IPC system that works for Android is
Binder which provides for a way for Android applications to communicate
with system services implemented as servers as well as other components of
the applications like Android Intents. The remaining IPC mechanisms are a
by product of having components that implement or provide such IPC
mechanisms.
The Linux kernel supports the standard IPC mechanisms that Linux based
operating systems support23, namely UNIX pipes, named pipes and System V
IPC. However, due to the modifications that are made by Google to the
Android Linux Kernel, System V IPC support in the libraries (Bionic) are left
out. The standard Linux IPC mechanisms are most evident when using the
shell through the Android debug bridge. Piping output from programs to
other programs is shown to work properly by doing a process listing with a
search on the word “system_server” or ps | grep system_server.
As Android applications are first written in Java, complied into Java bytecode
and then translated into Dalvik bytecode, there has to be support for native
Java libraries. Of these, support for Java’s Socket and Native IO or New IO
15
23 Linux interprocess communications. (1996, May 29). Retrieved from http://tldp.org/LDP/lpg/node7.html
which has been around since Sun’s J2SE 1.4 release24. Consequently this has
to be built into the Dalvik VM.
Lastly, DBus support exists in a small subset as it is utilized by the GPL Bluez
Bluetooth subsystem 25. DBus communicates with the system_server via its
own DBus IPC mechanism.
Figure 4.4.3.1 In depth Android Software Stack 26
Binder is Android’s solution to the need for a way to communicate between
Dalvik processors. This is important because the root Dalvik process forks
new applications as actual Linux processes in order for enforcement of Linux
permissions via the UID/GID. This is especially important as system services
are held by the system_server process and in order to use them, Binder has
to be invoked to handle message passing to and from the other processes.
16
24 Jsr 51: new i/o apis for the javatm platform. (2002, May 09). Retrieved from http://www.jcp.org/en/jsr/detail?id=51
25 Yueh, E. (2009, June 26) Android Bluetooth Introduction retrieved from http://www.slideshare.net/erinyueh/android-bluetooth-introduction
26 Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server
Binder also provides for security by authenticate the sender and the receiver
of IPC messages ensuring that only applications with permissions to access
capabilities and information the various mangers they are requesting actually
happen. The Android Interface Definition Language is one of the ways to help
ease the development of providing an IPC interface for other application
whom you want to provide services for. Binder also exposes a device file in
the /dev directory by the name of binder.
4.4.4 Application Binary Interface
While Android applications are shipped as Java to Dex binaries, being a
operating system that uses the Linux kernel requires it to adhere to the Linux
Application Binary Interface (ABI) when it comes to binaries that are written
in native code.
jeremy@jeremy-ubuntu:/media/B9EC-1701$ file chownchown: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped
Using the Android Debug Bridge (ADB) shell, the chown binary was copied
from the /system/bin directory into the /sdcard directory on the Nexus S.
The SD Card on the device was then mounted in Ubuntu Linux and the chown
binary passed to the file tool to determine what sort of file it was. As shown
from the output, the chown binary on Android is basically a Linux ELF binary
that is compiled to the ARM instruction set.
jeremy@jeremy-ubuntu:/media/B9EC-1701$ file dalvikvmdalvikvm: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), stripped
This is not isolated to POSIX utilities, Android specific servers, even the
Dalvik root process (zygote) are also ELF binaries. This further reinforces the
fact that Android is a Linux based operating system, however, the
implications of this is far reaching. Developers can technically write native
applications that compile to ARM and execute them instead of creating
libraries using the NDK and execute functions within the libraries through
17
the Java Native Interface (JNI) which allows native code to be called from
Java applications..
Building native binaries that work with Android does have a caveat.
Compiled binaries need to link to Android’s version of the standard C library
(Bionic) in order for these binaries to execute on the device. Beyond that, the
binaries are free to implement their own libraries and even use the suite of
shared libraries in the /system/lib directory to compile against.
4.4.6 The Managers
Like desktop Linux distributions, Android runs numerous servers that
provide for the different aspects of the operating system, from handling of
audio, display to security. Servers which are compiled to native binaries
largely execute out of the /system/bin directory with some exceptions from
the /sbin directory.
However, Android largely implements the rest of their servers in Java
compiled to run as components under a main Dex binary, system_server27.
This of course requires the Dalvik VM to be started prior to the system server
and thus the startup process generally starts the Dalvik root process, zygote
as early as possible to provide an environment for the other managers to
start.
Figure 4.4.3.1 lists some of the different managers that the system_server
encapsulates. Binder providers for a way to allow other applications to access
these services in a secure and authenticated manner. It is interesting to see
Google write their managers in Java while at the same time calling out to
native libraries using JNI to access the hardware itself. These managers are
typically implemented as Android Services and have their sources in the
18
27 Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server
frameworks/base/services/java/com/android/server directory of the
system source tree.
Analysis of the source code provides some insight into some of the following
managers,
• Activity Manager handles the lifecycle of Android applications from
starting to termination.
• Package Manager handles installation/removal of Android applications.
• Window Manager handles the display and general view related activity
that applications depend on including orientation and layering.
• Notification Manager deals with all the notifications that pop up and
anything related to it.
• Power Manager handles the power management of the device, whether
its on, off or locked. It uses the wakelocks mechanism.
• Location Manager handles the location gathering aspect of the device via
the various means via radio that are present on device and provides a single
point where applications can get location information that pertains to the
device.
4.4.5 Startup Process
The startup process for Android is fairly the same as any traditional Linux
distribution up to the execution of the init binary. From there on it takes on a
entirely different flow.
Examination of the init.rc script shows that the very first service that is ever
started is the ueventd daemon. This is Android’s version of the udev daemon
for Linux and has the same behavior where it manages device nodes in the
/dev directory as well as all user space actions related to removal and adding
19
of devices. This is done such that the init script can setup environment
variables and mount the file system for further booting.
Once booting is complete, the daemons are started by using the service script
to launch and maintain the daemons that are needed. In particular, the
servicemanager daemon which basically deals with management of Services
that Android applications can contain.
Figure 4.4.5.1 Android Startup Flow 28
20
28 Printemps, G. (2008, September). Deep inside android.. Presentation presented at Openexpo 2008 - zurich. Retrieved from http://www.openexpo.ch/fileadmin/documents/2008Zuerich/Slides/33_Printemps.pdf
It is after the service manager has loaded is the root Dalvik process (zygote)
started via the the app_process tool which sets up the runtime environment
and starts the application. zygote then basically takes over the duties of
launching and forking any Android application that is started, first order of
business being the start of system_server which then registers all its
managers through binder to the servicemanager daemon.
zygote is a particularly interesting process as it is the root Dalvik process that
forks and spawns the other applications that are launched. Analysis of its
code29 shows that it is expressly written in Java and make JNI callbacks to
actually fork processes. It is designed to allow a VM instance to be partially
initialized such that it can be used as the environment for new applications
that have been launched to fork with.
4.5 Third Party Development
There are 2 officially sanction ways to develop for the Android platform.
Preferred of which is the Android SDK which is a first class citizen on the
platform. This is a managed programming environment which has a runtime
that acts as a intermediary to the operating system and its services.
Recognizing that there might developers that would want to port their
applications from other platforms, Android also provides a native
development kit or NDK and provides closer access to the hardware through
the C/C++ libraries that work with the NDK.
4.5.1 Software Development Kit
The Android Software Development kit is a set of tools and libraries that
allow developers to write Android applications in Java which in turn are
compiled and converted into Dalvik runtime compatible intermediate code.
21
29 See /libcore/dalvik/src/main/java/dalvik/system/Zygote.java in the system source tree
These are usually packaged into .apk files which are zlib compressed archives
of the compiled application code as well as assets, resources and meta data.
While most Java specific libraries can be used, access to Android specific API
has to be made to the android.* name space. Google has released plugins for
Eclipse and NetBeans to aid in Android development and these IDEs are able
to help in autocompletion of code. Additionally, Google provides tools that
help in various aspects of Android development, from debugging to running
and testing applications in an emulator.
While Google encourages the use of Java for Android development, going as
far as making it a first class citizen on the platform by even writing their
services daemons using it, there are other languages that are unofficially
supported. These make use of the fact that Dalvik is pretty much a Java
Virtual Machine and any JVM compatible languages should work.
Additionally, because Dalvik is open source, a list of opcodes that it supports
can easily be found in the /libcore/dalvik/src/main/java/dalvik/
bytecode/ directory in the system source tree. It is then a trivial matter to
write a compiler that can generate an actual Dex binary that allows the Dalvik
VM to execute. A language that has preliminary support is the JVM based
Clojure30 though at this point in time is slow to execute31.
4.5.2 Native Development Kit
The Native Development Kit allows developers to create libraries in C/C++
that can be executed via the Java Native Interface (JNI) from Android
applications. This is primarily to help developers port their existing code that
are C/C++ based over to Android. The currently supported instruction sets
22
30 http://www.clojure.org
31 Gómez, D. S. (2011, February 04). Creating android applications with clojure, part 1 [Web log message]. Retrieved from http://www.deepbluelambda.org/programming/clojure/creating-android-applications-with-clojure
that the NDK complies for are the 2 ARM architecture that Android supports
as well as an x86 instruction set for execution on x86 devices.
While the libraries are compiled to native code, the execution environment
when the calling application runs still exists within the Android application
execution context. And even then, not all applications will benefit from being
in native code.
At this point in time, Android does not officially support the creation of
native binaries through the use of the NDK or any other means. It is however
possible to cross compile binaries using the tools from the system source tree
of the Android open source project as long as the final binary, should it use
standard library functions, be linked to Bionic and other dependents that are
Android specific.
It is interesting to note that Google does make extensive use of the NDK by
having their own services implement C/C++ libraries to allow access to
hardware and other aspects of the platform through JNI. Binder is an
excellent example of how IPC calls are abstracted using JNI.
23
5. Security Audit
By establishing understanding of a particular system, knowledge gained can
be reinterpreted with a security bias in order to understand what are the
security implications of the said system. Knowledge about known
vulnerabilities can also be used to further help with the analysis. For the
purposes of this discourse and to maintain context in a fast changing
landscape32 when it comes to platform releases, the target system is set at
Android version 2.3.x for the Nexus S device.
Traditionally, security analysts will look at individual components of the
system and test if there are vulnerabilities. This might include a code audit if
source code were available, or via more modern methods like fuzz testing.
Fuzz testing 33 feeds random or specially crafted data to the inputs of any
computer program and monitors for any exceptions that might be generated.
However, modern protection of computer systems and consequently more
sophisticated attacks have forced security audits to be a holistic endeavor.
Individual component vulnerability testing is important, but must also be
understood in the context of the system. Small errors in programs on their
own may no cause major issues, but used in conjunction with multiple errors
in code might give attackers a means of attacking a system. Return Oriented
Programming 34 (ROP) is one good example of such methods.
Open source security issues of the Android Platform
24
32 Garretson, R. (2010, June 04). google to ease android upgrade cycle [Web log message]. Retrieved from http://www.ciozone.com/index.php/Mobile-and-Wireless/Google-To-Ease-Android-Upgrade-Cycle.html
33 Sutton, M., Greene, A., & Amini, P. (2007). Fuzzing: brute force vulnerability discovery. Addison-Wesley.
34 Buchanan, E., Roemer, R., & Savage, S. (2008, August). Return-oriented programming: exploits without code injection. Retrieved from http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html
5.1 Existing Protection
Google explicitly states35 that security architecture of the Android platform
comprises of a privilege-separated operating system where each application
is uniquely identified. These applications can then, based on their identities,
request permissions and be granted said permissions in order to have
capabilities to execute certain processes.
What is not mentioned is that very fact that there are actually 2 permissions
models in play. Of which the more obvious is the Android application
permissions model and the lesser mentioned Linux Discretionary Access
Controls.
Linux DAC
Android Permissions Model
Android Dex Binary
Linux ELF Binary
Figure 5.1.1 Permissions Model Hierarchy
As show in Figure 5.1, the Linux DAC is the encompassing permissions model
that the the Android Permissions model has to obey. In practice, they actually
complement each other by having any Android application first respect the
Android Permissions model first for all capabilities it needs then respecting
25
35 Security and permissions. (n.d.). Retrieved from http://developer.android.com/guide/topics/security/security.html
the Linux DAC, based on the UID and GID it was assigned as a package, for
file access.
The Linux DAC is also precisely how Android “sandboxes” individual
applications through assignment of unique UID and GIDs upon installation.
5.1.1 Application Signing
All application packages are signed with a certificate that the developer holds
onto. Google does not require the certificate to be signed by a certificate
authority as the purpose of the certificate is to distinguish application
authors. As such, self signed certificates can also be used by developers.
Application signing allows Android to make certain decisions related to the
application36, chief of which is the ability to share code and data if
applications are signed using the same certificate. Additionally, application’s
can only be upgraded if the upgrade has been signed with a certificate that
matches the existing application’s certificate. Otherwise, developers will be
forced to assign a different package name and thus installs a completely new
version.
While application signing is good for verification of integrity of applications,
the lack of a trusted central certificate authority is troubling. Along with that,
the fact that developers do not need to have a private certificate maintained
with the Android Marketplace further nullifies the good that a signing
applications will do.
26
36 Signing your applications. (2011, October 03). Retrieved from http://developer.android.com/guide/publishing/app-signing.html
There are established37 ways38 to resign apk files but the gist of the whole
thing is that every apk file being a zip archive can be uncompressed. Within
this compressed archive is a META-INF directory which contains the
signature that is associated with the application. It is just a simple matter of
removing that signature and resigning the apk after modification to once
again have a valid application.
Close examination of the META-INF reveals 3 files that are tied to the
signature and certificate of the application. They are the CERT.RSA, CERT.SF39
and the MANIFEST.MF40 files corresponding to the certificate used to sign the
application, the list of SHA-1 hashes that are the signatures of the individual
files in the application package, and the manifest SHA-1 hashes respectively.
It is therefore a trivial affair to resign an existing apk after it has been
modified.
This method would be easily defeated if there is a trusted central certification
authority that the security framework can ensure the certificate is issued
from. It is understandable that because of the open nature of the operating
system, that such a system was not put in place. But it does make prudent
sense to at least have such verification functionality for proprietary
distribution systems such as the Android Marketplace.
5.1.2 User IDs and File Access
A Linux User ID is assigned to each package that is installed on the device.
This UID is unique per device and does not carry to any other devices that the
27
37 Stericson. (2009, January 16). [how to] manuals for creating a theme view single post [Online forum comment]. Retrieved from http://forum.xda-developers.com/showpost.php?p=3175518&postcount=2
38 bonsey. (2010, May 22). Java jdk,android sdk and resigning apk's [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=686341
39 See Appendix “Sample CERT.SF”
40 See Appendix “Sample MANIFEST.MF”
same user might own. Correspondingly, a group ID or GID similar to the UID
is also assigned to the package.
This allows the use of POSIX filesystem permissions to be assigned to
filesystem items and thus provide a context for the application when it is run.
Filesystem item access through APIs respect this context and “sandboxes”
applications in their own context.
Interestingly, when creating files using the MODE_PRIVATE,
MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE flags for
the official Android SDK file creation APIs, little changes are made to the
permissions associated with those files. Files still retain only permissions for
reading and writing by the owner. This leads to speculation that file access
APIs got through the Dalvik runtime’s permission checking.
Android also does not maintain a passwd or shadow file like other
distributions of Linux. Symbolic mapping of UID to users are actually done in
a header file located in the platform_system_core repository under the
android_filesystem_config.h file41. This file provides a direct 1-to-1
mapping of the different UID/GIDs that is used by filesystem image building
tools to set the correct owners and groups when creating the images that will
be flashed onto devices. In order to maintain parity with Linux filesystem
features, stubs were written as a go between for the Google developed
standard C library, Bionic. Additionally, uid and guid permissions are also set
by the init script as part of the boot phase of the operating system.
In short, the Android security model relies on the traditional Discretionary
Access Control (DAC) that Linux provides. A paper published by the National
Institute of Standards and Technology (NIST) in the United States on the
28
41 See Appendix for “Android Filesystem Configuration Header”
Assessment of Access Control Systems42 argues that the use of protection bits
in Linux DAC schemes is too coarse grained and is not able to provide fine
grained access to resources. This results in the need for the owner of the
resource to violate the principle of “least privilege” by setting protection bits
that work the best for all users of the particular resource.
The customizations to how the Linux DAC works on Android further
complicates matters. The lack of a shadow file means that as long as an su
binary exists and can be executed, the path to root access is unhindered by
passwords.
5.1.3 Permissions Enforcement
The Android permissions model enforces what extra capabilities an
application might possess beyond the ability to do computation. This is
specified at the package level through the Android manifest configuration file
and will be shown to the user at install time for approval before installation.
These permissions deal with capabilities from the ability to access the
internet (or have access to the networking stack), writing files to locations
outside the private data directories, accessing user information like their
address book or user accounts stored on system, using hardware that is
available on the device to being able to read text messages that are on the
device.
29
42 Hu., V. C., Ferraiolo, D. F., & Kuhn, D. R. National Institute of Standards and Technology, Computer Security Division. (2006). Assessment of access control systems (Interagency Report 7316). Retrieved from http://csrc.nist.gov/publications/nistir/7316/NISTIR-7316.pdf
Figure 5.1.2 Android Application Installation and Permission Request
To date, there are a staggering 117 43 different permissions that developers can
request. It is quite a feat for users who have no technical knowledge to be able
to even begin to understand what these permissions mean and how to act on
them.
With such numerous permissions, Android allows for application developers
to request a set of permissions as limited as possible in order to allow their
applications to work. While this is a valid security practice, few developers
actually follow it as it is not as convenient as requesting as broad a set as
possible.
30
43 Manifest.permission. (2011, October 03). Retrieved from http://developer.android.com/reference/android/Manifest.permission.html
Figure 5.1.2 BlackBerry Application Permissions
Additionally, while the permissions allow fine grained access to capabilities,
the approval system is disconnected from broad choice, only allowing an
application to be installed if all permissions requested are approved. There is
no fine grained control over what is actually allowed in the end, unlike
BlackBerry devices which has individual toggles for access to system
properties and capabilities.
5.2 Attack Surface
The Android attack surface is a broad one where there are multiple points of
entry for security to be compromised. At DEFCON19, a sophisticated attack
on Android devices44 was carried out that required no user interaction.
Allegedly it was done through a man-in-the-middle attack on Android devices
that got privilege escalation and thus control of the device.
Additionally, this attack was able to masquerade as the Android Marketplace
and force the upgrade of applications that were not the actual copies from the
official Android Marketplace. What is interesting about this attack is that it
made use of multiple vectors, chained them up to achieve its goal.
It still does goes to show that the Android attack surface is pretty wide.
31
44 coderman. (2011, August 2011). Def con 19 - hackers get hacked! [Electronic mailing list message]. Retrieved from http://seclists.org/fulldisclosure/2011/Aug/76
5.2.1 Android Marketplace
The Android Marketplace is a very interesting vector to attack from because
of the way it works and the ubiquity on almost all Android devices. It is
perhaps one of the most efficient forms of delivery for Android malware due
to Google’s relaxed stances towards app review.
However more sophisticated methods are available though Google has
patched vulnerabilities that have been reported. This involved the use of
Google’s own communication channels45 to Android Market servers to allow
arbitrary installation of applications. This GTalkService46 is a persistent
connection to Google servers and is the communication channel that the
Android Marketplace application uses to install applications.
It is also not difficult to imagine a scenario where a man-in-the-middle attack
occurs that masquerade as the Android Marketplace. This was suitably
demonstrated at DEFCON19 and most likely have made use of Jon
Oberheide’s research into the special commands47 that the Android
Marketplace uses to install applications.
As a sidebar, Jon also seems to have discovered a XSS vulnerability 48 in the
web version of the Android Marketplace that allows for arbitrary remote code
execution for devices though the bug since has been reported and fixed. This
32
45 Oberheide, J. (2010, May 28). When angry birds attack: android edition [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/
46 Oberheide, J. (2010, June 28). A peek inside the gtalkservice connection [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the-gtalkservice-connection/
47 Oberheide, J. (2010, June 25). Remote kill and install on google android [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/
48 Oberheide, J. (2011, March 07). How i almost won pwn2own via xss [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/
just expands the likely attack vectors that the Android Marketplace fully
presents.
Beyond what is technical, the Android Marketplace also represents a vector of
attack in the form of social engineering.
5.2.2 Dalvik
The saying you are only as strong as your weakest link applies heavily with
regards to the Dalvik attack surface. Because so many applications depend on
the VM, it is one of the single point of failure and also perhaps a good vector.
Knowing that the root Dalvik process has to have the capability to fork
Android applications as they are launched means having the process run as
root. It is then a simple matter of using what is know about Dex binaries and
opcodes to find a vulnerability such that an exploit will allow the attacking
process to take the root credentials of zygote.
Since the VM interprets bytecode, it is then a simple matter of either code
analysis to look for vulnerabilities or the more sophisticated approach of
using fuzzing49 to determine Dex binaries that will trigger exploitable bugs.
Once this exploit is found, it is just a simple matter of crafting a Dex binary
that can trigger the exploit.
5.2.3 Networking & Services
The netstat output50 from Android reveals an environment where there are
few listening services which limits attacking vectors against listening servers.
However a persistent connection to port 5228 exist which suggest strongly
33
49 Neystadt, J. (2008, February). Automated penetration testing with white-box fuzzing. Retrieved from http://msdn.microsoft.com/en-us/library/cc162782.aspx
50 See Appendix “Sample netstat -a output”
that this is the GTalkService with a IP address range ownership check as
belonging to Google to further confirm it.
Based on the attack at DEFCON19, it is possible that the attack forced the
device to connect to a compromised access point such that the operating was
forced to reconnect to the GTalkService servers. This creates an opportunity
where the attackers could route such a traffic to their own systems and thus
work the man-in-the-middle-attack in.
5.2.4 Code Execution
Without a doubt, one of the weirdest APIs that ever existed for Android
applications is the ability to call out to the shell and execute commands using
the Java API call of Runtime.getRuntime().exec(“Command”). It adds to the
bad decision that this API exists by not having an Android permission that
allows or disallows execution of such an API call.
A sample application51 was written with absolutely no permissions requested
from the user and its main aim is to see if it can find a place to write a script
as contents to a file, set it as executable and then execute it. The success of
such an application means that this alternative way of code execution would
allow a maliciously crafted kernel exploit to be packaged with an Android
application, dropped in the data directory of the application and executed,
gaining the application super user credentials to execute its payload.
Beyond this, it would also seem that it will be possible to craft a binary that
the NDK can compile that is able to make system calls to the kernel directly.
This can then be legally executed through JNI from the main Android
application.
34
51 See Appendix “11.9 Android Application to Test Permissions and Runtime.Exec”
5.2.5 Kernel Vulnerabilities
With the Linux kernel in use being a few revisions behind the mainline,
existing kernel vulnerabilities that have already been reported can still be use
in exploits. Additionally, because of the pace of updates that trickles down
from Google to its OEM partners, these exploits can still be used for a very
long time on OEM devices long after Google has patched its Google phones.
It is thus a trivial matter to use existing kernel vulnerabilities as a final stage
payload for malicious applications as these are easily available in bug
databases and sometimes with accompanying source code.
5.3 Chain of Trust violation through Full Access
While Android does not live in a jail like the iPhone, this truth goes as far as
the manufacturer of the device that the operating system is run on. In the
case of the device used as a reference in this report, there are very few
obstacles that prevent the further opening up of the device.
For OEM partners, it is a different matter entirely. The different
manufacturers implement different policies when it comes to giving
customers access to their device. Most have a secure bootloader that doesn’t
allow non signed firmware updates. But the general idea is to prevent
customers from flashing customized firmware onto their devices.
On Google’s end, they have removed the presence of the su binary in the
operating system. The su binary or superuser binary allows the invoker to set
itself as the root user of the operating system, thereby gaining super user
credentials that basically ignores all set Linux DAC policies.
35
Figure 5.3.1 Ideal Trusted Execution Path
Measures taken by OEM partners and Google ensures a pseudo trusted path
of execution for applications and services on the device through the
prevention of tampering from the lowest levels of the boot chain to the
highest level of application execution. This ensures that every component in
the execution chain are implicitly trusted and thus would execute correct and
safe applications.
Of course this runs counter to the notion that devices that run Android
should be open and thus spawn two jargons associated with gaining full
access to the device, Unlocking and Rooting. They pretty much compare to
the idea of jailbreaking iOS devices from Apple, except that on Apple devices,
it is an umbrella term.
5.3.1 Unlocking
The term unlocking comes from getting the bootloader of Android devices to
accept and flash custom firmware onto the device. This is different from the
process of removing the hardware lock that is placed by the carrier on the cell
radio of the device. While this is a simple command that can be issued to the
low level bootloader on Google phones, it is much more complicated on OEM
devices as they are locked down.
Low Level Bootloader OS Bootloader Kernel init
zygoteAndroid Application
Starts Loads Runs
Starts
Starts
36
Figure 5.3.1.1 Nexus S Low Level Bootloader
For Google phones, to unlock the bootload is simply using the Android Debug
Bridge (ADB) to boot into the bootloader itself. Once that is done, use the
fastboot tool that is available in the system source tree and issue the
command “fastboot oem unlock”. Confirm the choice and the low level
bootloader will allow you to flash any custom firmware that you may have.
37
Figure 5.3.1.2 Nexus S unlock bootloader confirmation
For OEM partners, this is a different story. The only other manufacturer that
has allowed an unlocked bootloader 52 is HTC which was announced in a
statement by their CEO on Facebook53. The most notorious of which is
Motorola which has additional protections54 to ensure that their bootloader is
not compromised. This required much work55 from the Android community
to look for an exploit that works with the bootloader such that it can be used
to allow custom firmware to be flashed onto the device ROM.
38
52 http://www.htcdev.com/bootloader
53 Chou, P. (2011, May 27). Statement from htc ceo [Facebook message]. Retrieved from https://www.facebook.com/HTC/posts/10150307320018084
54 Ziegler, C. (2010, July 16). Motorola responds to droid x bootloader controversy, says efuse isn't there to break the phone [Web log message]. Retrieved from http://www.engadget.com/2010/07/16/motorola-responds-to-droid-x-bootloader-controversy-says-efuse/
55 "cellulararrest". (2009, December 09). [droid] root instructions (updated) [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=597175
5.3.2 Rooting
Rooting is usually the next thing that comes after unlocking the bootloader as
rooting usually occurs by allow custom firmware that comes with the su
binary already installed to be flashed onto the device. This allows the users
and applications that request super user credentials56 to actually be able to
obtain the user ID of 0 or root thereby giving them permission to do anything
on the device. The method of getting root is basically the same as obtaining
super user credentials from the command line.
Once again, Google phones have the advantage when doing this because of
their unlockable low level bootloader. The su binary can be packaged as an
update and installed using the low level bootloader to flash it to the system
mount point.
OEM devices that have a protected bootloader either has to resort to exploits
on the operating system to gain root access first before writing the su binary
into the system mount point. Or they have to first unlock their bootloaders to
allow custom ROMs which already have the su binary to be flashed onto the
device.
5.4 Existing Security Compromises
Android is not spared from its fair share of security compromises. What is
particularly worrying is that the trend seems to be going upwards despite
Google and Enterprise Security companies’ best efforts to prevent such such
issues.
39
56 Rollings, M. (2010, January 17). Android: requesting root access in your app [Web log message]. Retrieved from http://www.stealthcopter.com/blog/2010/01/android-requesting-root-access-in-your-app/
Paolo Passeri, an ex Security Consultant published his list for 2011’s One Year
of Android Malware57. This list contains about 30 malware that have been
active from 2010 to 2011. The malware threat is real even though it doesn’t
seem to carry much wait in the press. Mcafee’s Threat report from the 2nd
quarter of 2011 58 also supports the notion that Android malware has had a
sharp increase.
Apart from malware, data leaks through custom applications written by
OEMs for carriers are also another interesting class of security compromises
that was not intentional.
5.4.1 Malware
While most malware is concentrated in China, two of the more interesting
ones are the DroidDream59 and Gemini60 malware. Both are trojans that have
been grafted to existing applications and re-released to pose as the actual
legitimate copy. They also exhibit botnet like behavior, calling home to
command and control servers for updates as well as new instructions in
addition to their originally intended task of which it seems is to gather private
user information.
DroidDream being the newer malware on the market also exhibits an
interesting quality of having an exploit payload (RageAgainstTheCage61) that
40
57 Passeri, P. (2011, August 11). One year of android malware (full list) [Web log message]. Retrieved from https://paulsparrows.wordpress.com/2011/08/11/one-year-of-android-malware-full-list/
58 Mcafee labs (2011). Mcafee threats report: second quarter 2011. Retrieved from http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q2-2011.pdf
59 Kevin. (2011, March 01). Update: security alert: droiddream malware found in official android market [Web log message]. Retrieved from http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/
60 Android.geinimi. (2011, January 01). Retrieved from http://www.symantec.com/security_response/writeup.jsp?docid=2011-010111-5403-99&tabid=2
61 Lineberry, A. M. (2010, August 25). Reversing latest exploid release [Web log message]. Retrieved from http://dtors.org/2010/08/25/reversing-latest-exploid-release/
was designed to help it break out of the application sandbox using a bug in
the Android Debug Bridge (ADB) and install new applications without user
intervention.
5.4.2 Info-sec data leak
Analysis of updates62 to some HTC devices have revealed a whole suite of
logging tools that collect information. While there may have been legitimate
uses for them, the implementation has been less than ideal that it would
cause a data leak. This in particular is something that Google cannot control
as this is an OEM specific issue.
The data leak in question comes about due to the way one particular logger
works. Internally, it has a service which it tries to run as root such that more
data can be logged. It also exposes a service interface on port 50240 that does
not require authentication. Any application on these HTC devices can then
get access to all the data that this logger currently works with by just
requesting access to the INTERNET permission. This makes exfiltration of
information from the logger and easy task without seeming suspicious.
Another example63 of such third party data leaks is by the VOIP application
“Skype”. A mistake in its implementation had its data directories containing
private data readable by everyone most likely caused by the
MODE_WORLD_READABLE mode. What make things worse is that these
data are unencrypted, so any application is able to read and parse Skype’s
sqlite databases.
41
62 Russakovskii, A. (2011, October 05). Massive security vulnerability in htc android devices (evo 3d, 4g, thunderbolt, others) exposes phone numbers, gps, sms, emails addresses, much more [Web log message]. Retrieved from http://www.androidpolice.com/2011/10/01/massive-security-vulnerability-in-htc-android-devices-evo-3d-4g-thunderbolt-others-exposes-phone-numbers-gps-sms-emails-addresses-much-more/
63 Case, J. (2011, April 15). [updated] exclusive: vulnerability in skype for android is exposing your name, phone number, chat logs, and a lot more [Web log message]. Retrieved from http://www.androidpolice.com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/
5.5 Conclusion
It is fairly obvious that the problem with Android was that security was never
a top priority when it came to its development. Three major revisions to the
platform has seen no improvements in the security model since its inception
while feature sets and preserving the status quo of an open platform seem to
take precedence. With such a wide attack surface open, it is a wonder why
there has not been more cases of Android devices being compromised.
42
6. Securing Android
As demonstrated, Android is quite a beast to tame. Therefore it is no surprise
that having a one size fits all solution is less likely to work than a holistic
approach that touches various parts of the operating system as well as
workflow itself.
A driving philosophy behind the securing of the platform is needed in order
to provide a clear plan of action that will improve security on the entire
platform holistically. It is then appropriate that the National Security Agency
also agrees64 on this point that there has to be a holistic plan for security on
modern operating systems.
While protecting users is the main goal of security measures, there is an
added side benefit to developers who are writing third party applications. It is
naive to think that security only affects users. By securing and protecting the
system, methods that can be used to pirate applications would become
significantly harder to implement, and consequently will help reduce piracy.
6.1 Philosophy
Mobile devices are now ubiquitous. Putting it into perspective, close to 60%
of the world population own mobile phones65 whereas only about 0.01607%
Open source security issues of the Android Platform
43
64 Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R. C., Turner, J. S., & Farrell, J. F. (1998, October). The inevitability of failure: the flawed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml
65 "Personal computers (per capita) by country", World Development Indicators database. Retrieved from http://www.NationMaster.com/graph/med_per_com_percap-media-personal-computers-per-capita
own computers66. Some people who own mobile devices do not even own
computers67. It is very obvious that the security model applied to computers
does not apply to mobile devices.
A huge reason why the old security model that used to apply to computers do
not apply to mobile devices is simply because these devices are more
accessible to people who might be computer illiterate. These people do not
understand the jargon nor know that sometimes what is put up online might
be malicious.
Much inspiration was drawn from the marvelous work done by Ivan Krstić68
on the BitFrost security architecture for the OLPC project. Ivan was the
Director of Security Architecture while he was at the OLPC project69 and now
works for Apple in core security for their OS X and iOS platforms. Much of
his work is now present in the latest release of Mac OS X Lion as well as the
release of iOS 5, of which the former had plenty of accolades by security
researchers70.
The OLPC project runs each application in isolation in its own virtual
machine. It uses a customized version of Linux Vserver 71 in order to achieve
this functionality as OLPCs do not run on powerful hardware. The security
model employed also takes into consideration that the project’s source code is
44
66 "Mobile phones by country", International Telecommunication Union. Retrieved from http://www.NationMaster.com/graph/med_mob_pho-media-mobile-phones
67 Worthington, D. (2011, March 28). My mom reviews the ipad, her first computer [Web log message]. Retrieved from http://technologizer.com/2011/03/28/my-mom-reviews-the-ipad-her-first-computer/
68 http://radian.org/
69 Krstić, I. (2007). OLPC Bitfrost.Olpc. Retrieved from http://wiki.laptop.org/go/OLPC_Bitfrost
70 Fisher, D. (2011, July 21). Apple revamps security in os x lion [Web log message]. Retrieved from https://threatpost.com/en_us/blogs/apple-revamps-security-os-x-lion-072111
71 http://linux-vserver.org/
open source and does not employ security by obscurity. Additionally, security
is unobtrusive and does not get in the user’s way.
While placing processes in their individual VMs are the gold standard72 for
security like what Invisible Things Lab is doing with their Qubes73 operating
system, they are complicated to maintain and do take up significantly more
computing resources. This is not ideal on mobile devices as they already have
limited computing resources that have to be shared with applications that
run on the system.
Designing any security measures for mobile devices will have to take into
consideration the fact there will be limited computing resources to make use
of. Any security measures should philosophically be able to operate in such
conditions and be considered before implementation.
6.1.1 Users are not to be trusted
It is clearly evident from the figures that show the number of people owning
mobile phones versus computers that there will be a large number of people
who have never previously used a computer before. They have no experience
with the paradigms and jargons used when it comes to computing.
By labeling the user as a hostile entity that possibly might cause harm to the
system whether through ignorance or intentional, the security model will
effectively encompass the 2 types of people most likely to bring harm to the
system - the attacker and the ignorant.
While the principle sounds harsh, it provides for a mindset that anything
other than the system is likely to cause harm and therefore defensive
45
72 Vervloesem, K. (2010, May 05). Qubes: security by virtualization [Web log message]. Retrieved from http://lwn.net/Articles/385213/
73 http://qubes-os.org/
measures should be taken. Additionally, this principle also means that in
order to tackle ignorance, better ways of dealing with permissions must be
designed.
While the current Android permissions system is fine grained, it does require
some technical background to know what they really are about. Users should
not have to deal with this. Choice is a good thing, but ultimately everyone
only makes one - the best. It should not be a difficult task to account for
which is a good choice by reducing the number of permissions that the user
has to know about and grouping them. Additionally, permissions that are
most likely to trigger privacy concerns should be requested separately on
demand.
Additionally, instead of presenting all options available to users, the best one
should instead be weeded out and the decision made for the user. This
immediately provides an environment where the vectors are controllable
instead of having to cover all bases.
6.1.2 Prevent instead of Reacting
Most commercial security solutions for the Android platform to date rely on
signatures and reacting to security threats. This requires that updates are
made as often as possible to these solutions in order to secure the system.
While ideal, it does mean that security is reactive and might just be too late at
times to deal with new or unknown threats (0-day).
Security should be a proactive approach. It should involve writing correct
code as much as possible. Reduction in possible vectors of attack by limiting
the numbers exposed. Developing preventive measures that are all
encompassing instead of the old model of specific detection and cleaning.
46
Should closing such vectors not be ideal, implementation of low level security
measures that act as a gatekeeper is a good compromise. These act at the
basic foundation vector of any attack and shutting them down will go the long
way in preventing compromises.
6.1.3 Fix as soon as possible
Security vulnerabilities will always exist. Fixing them and releasing them as
soon as possible has to be made a priority in order to ensure that even with
all the protection that prevention offers, security compromises are hard to
come by.
Time taken to get fixes from the upstream down to OEM partners must be
improved upon and with current methods being shown as ineffective, a
rethink when approaching security fixes must be made. It is likely that
compartmentalization of common components that need security updates
and providing a mechanism that updates these independent of OEMs and
their customization might be key to such a system working.
6.2 Existing Work
There have been numerous efforts commercially to introduce security
measures to the Android operating system. The issue with these projects and
solutions are that they are rarely a holistic solution, covering on aspect while
still leaving loop holes.
6.2.1 Commercial
Every computing platform will have companies that try to provide security
solutions for and Android is no exception. Large companies like AVG
Antivirus and Symantec have a mobile version of their security suite. These
do pretty much the same job as their desktop PC components, providing
active measures against malware.
47
Smaller companies like Lookout are providing a custom suite of security
solutions that are not limited just range from detecting and removing
malware.
What is similar though is the way these solutions are delivered - as
applications on the Android Marketplace. While there is nothing wrong with
such a distribution method, these suites of application can still fall prey the
numerous malware that makes use of the social engineering vector of the
Android Marketplace by upload fake versions of these applications.
6.2.2 SELinux Android
SELinux Android or SE Android is a small project by Stephen Smalley 74 of
the NSA. It is an ambitious plan to bring SELinux to the Android platform by
patching the project to support the numerous idiosyncrasies that
differentiates the platform from traditional desktop Linux distributions.
It is pretty much still under development with only a prototype being
developed, but it does prove that such MAC systems can be implemented on
Android despite the hard work needed.
6.2.3 Android as a Hypervisor
A project out of the Fraunhofer Institute for Secure Information Technology
has produced a version of the Android operating that adheres to the goal of
isolation by virtualization.
48
74 67 Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf
Biztrust75 lets users create virtual phones within the operating system to
isolate different partitions for different uses. These partitions can have
different security policies applied to it, possibly giving the “work” partition
slightly more stringent security considerations than the “personal” partition.
It is a complete enterprise grade solution that is targeted towards businesses
that are keen on deploying Android as a corporate smartphone platform of
choice.
The only issue here is that such a solution is targeted towards businesses and
would be too impractical and complicated for use by consumers. Also, it is
not known how performance will be affected because of the virtualization of
the different virtual phones.
6.3 Mandatory Access Control
The Linux discretionary access control that Android relies on are just
sufficient for limiting access to files and directories. However, any modern
techniques of privilege escalation can easily defeat such permissions based
system by simply gaining root.
It has been successfully implemented on iOS and as a testament to its
effectiveness, has suffered no malware attacks despite its huge number of OS
vulnerabilities76.
49
75 UNGERLEIDER, N. (2011, October 10). The most secure android phone, ever [Web log message]. Retrieved from http://www.fastcompany.com/1786472/most-secure-android-phone-ever-blackberry-headache?partner=gnews
76 Nachenberg, C. (2011). A window into mobile device security. Retrieved from http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf?om_ext_cid=biz_socmed_twitter_facebook_marketwire_linkedin_2011Jun_worldwide_mobilesecuritywp
6.3.1 Operating System
Using discretionary access controls as a means of sandboxing has been
proven time and time again on the Android platform as not sufficient. There
has to be a partnership with MAC security policies in order to ensure that
security policies are actually effective and fine grained.
These access controls should work as close to the kernel as possible,
preferably loaded as a kernel module. This allows for good performance when
applying security policies as well as being close enough to bare metal that it is
the single point where these policies can be enforced.
Various MAC systems were evaluated but most promising were those that
supported Linux Security Modules (LSM). Of which, NSA’s SELinux 77 stood
out the most78 due to its flexibility and capability at handling complex
security policies. It also does MAC at the inode level of the filesystem instead
of directory based which prevents hard linking attacks. SELinux is also what
TrustedBSD79 is based upon which has been ported and adapted for Apple’s
Mac OS X operating system and more successfully implemented on their iOS
devices.
Having SELinux support easily enabled within Android’s Linux kernel
through compile options made it the best choice for a MAC system for
Android.
50
77 http://selinuxproject.org/
78 Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf
79 http://www.trustedbsd.org
6.3.2 Dalvik
However, because majority of applications are written in Java, compiled and
executed in the Dalvik environment, patches must be made to the Dalvik VM
to support these access control mechanisms through the labeling of resources
as well as the application itself. This is where the extended attributes of the
file system will come into play.
Additionally, the VM itself could be placed under a sandbox to prevent it
from becoming a possible attack vector should a maliciously crafted Dex
binary be started.
6.4 Hardening
Another aspect of improving security by preventing or reducing possible
attack vectors is the act of hardening a system against vulnerabilities. These
bugs may still exist, but the system itself makes it really difficult to exploit
and be useful to any malicious attacker.
6.4.1 Patching
The most basic of all is to constantly patch vulnerabilities by keeping
software updates. This is not limited to the kernel which is important, but
also every component along the trusted execution path.
Of course special attention should be paid to the Linux kernel as this is one of
Android’s weakest links due to its age. Patching its bugs is one thing, but
more importantly preventive measures should be taken to mitigate the
possibility that attacks can occur. For a long time, desktop Linux has had the
luxury of having grsecurity80 patches for the Linux kernel, so it is a fairly
obvious choice to include it for Android as well.
51
80 http://www.grsecurity.net
grsecurty is a bunch of patches to the Linux kernel that hardens it against
attacks. Things like ensuring proper functions that deal with overrun buffers
or compiling the kernel with more secure options are part and parcel of the
grsecurity package. These patches basically add special compile options to
allow system administrators to define security policies that effectively reflect
the principle of “least privilege”.
Additionally, the set of patches are also include the work done by the PaX81
project which are basically exploit mitigation techniques82 that further serve
to harden the operating system against attacks.
6.4.2 Reduce Vectors
Reduction of vectors involve making processes that are likely to be attacked
more benign. This can include a variety of methods of which setting proper
and appropriate UID bits is one of them. An audit of the functions of long
running services or system specific tools will give a clearer understanding as
to the sort of permissions that is needed. From there, MAC or even simple
DAC permissions setting can be applied.
One good example is the Bonjour daemon on Mac OS X. It is currently
sandboxed on the OS such that it only has the privilege to deal with network
connections and nothing more. It doesn’t have access to files and directories
so attacks against it to try to access files are mitigated. This is a proper
reduction of attack vectors.
Reduction of vectors can also come about by reducing the possible tools
malicious attacks can use to attack the system. Google has done something of
that sort by removing the su binary, however that is not enough. Closing
52
81 http://pax.grsecurity.net/
82 More explained in ASLR and DEP
vectors like the ability to execute commands on the shell makes the removal
of the su binary all the more effective.
6.4.3 Data Execution Prevention
Android devices currently ship with ARM designs as a processor package. It
is however a wonder why to this date the hardware based Data Execution
Prevention (DEP) features of these ARM chips are not put into use. Apple’s
iOS uses it to great effect to prevent arbitrary code execution as a result of
exploits that target gaining control of the program counter of the CPU.
DEP basically lets the operating system mark memory pages as either read-
write-noexec or read-exec, the core principle being memory which is
designated as data should not be allowed to execute, and memory that
contains program code should be allowed to read and execute but not write.
This prevents exploit techniques to rewrite the program code via overruns to
gain control of the program counter.
grsecurity includes patches from the PaX project83 that explicitly deals with
this problem. Additionally, should any CPU not support such features, PaX is
also able to emulate DEP such that operating systems can still take advantage
of the protection that DEP offers.
6.4.4 Address Space Layout Randomization
DEP with Address Space Layout Randomization (ASLR) is as good as useless.
Exploit techniques like return orientated programming’s84 return-to-libc
53
83 http://pax.grsecurity.net/docs/
84 Kane, D. (2009, August 11). Computer scientists take over electronic voting machine with new programming technique [Web log message]. Retrieved from http://www.sciencedaily.com/releases/2009/08/090810161902.htm
attacks85 basically defeat DEP by using pieces of other binaries that are
already in memory (most notably the standard C library) to form opcodes
that correspond to system calls to control the program counter once again.
This attack only works if the location of where the standard C library is
loaded in memory is know whether through discovery or because it is always
located at the same spot in memory. ASLR defeats this attack by randomizing
where libraries are loaded at load time. In fact, the entire address space is
randomized such that it is almost impossible to predict where a library may
be loaded.
grsecurity’s use of PaX is perhaps the most complete implementation of
ASLR, going as far as to even doing ASLR on the kernel stack. This provides
the most entropy as almost the entire memory space is randomize. As a
caveat, this requires binaries to be compiled with position independent code
(PIC) which will allow these binaries to be loaded anywhere in memory
without problems.
6.4.5 Using existing protections properly
Much more can be done to further protect the operating system from
tampering beyond implementing the measures presented above. This
involves the proper usage of protection mechanisms that come with Linux.
While it is understandable that Google needed a optimized version of Linux
that would work on mobile devices, changing large portions of the code base
including rewriting the way file system permissions are implemented
introduces the risk that such code is not mature.
The mantra that less code is better for the programmer always holds as this
means less chance for errors. The Linux kernel and Linux as an operating
54
85 c0ntex. (n.d.). Bypassing non-executable-stack during exploitation using return-to-libc [Electronic mailing list message]. Retrieved from http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf
system has had many years to mature its code base along with multiple
talented individuals working on it. It would be folly to try to rewrite certain
implementations and expect error free code considering the small team that
Android has86.
As mentioned previously under the security audit, getting permissions right
is also important. Closing loopholes like allowing shell execution access87 via
the Java API without purview by the Dalvik permissions model should also
rate highly in getting existing protections working properly.
55
86 Vaughan-Nichols, S. J. (2010, September 07). Android/linux kernel fight continues [Web log message]. Retrieved from http://blogs.computerworld.com/16900/android_linux_kernel_fight_continues
87 See 5.2.4 Code Execution
7. Proof of Concept
In the course of research and audits, some work was made towards a proof of
concept that a holistic approach to security on Android is a viable method
that would help in the mitigation of security compromises. This largely
involved work in Android’s Linux kernel as well as experiments in getting a
customized firmware to work. A simple test tool was also developed as a
benchmark to determine of the proof of concept worked.
This is still largely a work in progress as the amount of knowledge needed to
tackle these specific areas far exceed what is capable in the period of the
project.
7.1 grsecurity Patches
The grsecurity patches were chosen as the first component in the holistic
approach to security because they represented the best of breed to exploit
mitigation techniques on the Linux kernel. Also because they seemed the mos
straightforward to apply. The only problem was that there have been no prior
work in this area to get grsecurity working on Android. Understandably so
because of the numerous differences between the Android kernel and the
mainline Linux kernel that grsecurity was designed for.
Initial work with grsecurity on Android largely dealt with looking for the
specific patch that worked with the Nexus S’ 2.6.35.7 version of the Linux
kernel. While the main site does not contain anything beyond the stable
version of the kernel, the particular patch that was designed for Android’s
kernel was found on a mirror88 that held test versions of grsecurity. Test
Open source security issues of the Android Platform
56
88 http://mirrors.muarf.org/grsecurity/test/
versions are typically versions that exist because they are high in version
number than the stable version that grsecurity officially supports.
Getting the kernel patched and compile successfully was largely an exercise
in using the diff and manually applying some code changes manually to the
power management code in Linux because of the wakelocks mechanism.
However, upon applying the kernel image to the device, it failed to boot.
Likely theories as to why this is happening range from the unique standard C
library that the kernel cross compiles with to the fact that there are certain
compile options that grsecurity modifies that doesn’t let the kernel boot.
More time and more understanding into kernel development is need to find
fruition in this area.
7.2 Security Enhanced LinuxWith the amount of work put in by Stephen Smalley, it was an obvious choice
to use SELinux as MAC system for the proof of concept. The kernel support
for SELinux also tipped the decision in its favor.
Initial work to get SELinux compiled into the kernel and booting was met
with little resistance. However, with no reference to work with apart from a
conceptual understanding of how it was supposed to happen, modification of
the operating system to support SELinux has been difficult.
Successes were mostly made with getting it to run via the init.rc script and
setting policies on certain directories. Getting SELinux to work with the
Binder IPC mechanism required some knowledge into Binder and how
SELinux can integrate into Binder.
More work is needed in this area to get SELinux fully working properly.
57
7.3 Patching Dalvik
Based on the limited success with SELinux, work was turned to looking at the
possibility of patching the Dalvik VM to label applications as they were
forked. This was a fairly straight forward process which necessitated the need
to look through the Dalvik VM’s code to look for an entry point to add code to
set SELinux security contexts for apps.
More work can be done to match security contexts to Dalvik permissions
such that there is more consistent protection across the board.
7.4 Test and Audit Tool
The test and audit tool is basically a Android application that requests as little
permissions as possible and progressively through different means tries to
achieve super user access. This tool has evolved out of the original sample
application89 that tests to see if shell execution was able to be done without
need for permissions along with writing to a directory without permissions.
Additionally, for further enhances the testing tool, exploits were packaged
with the application and were executed in turn as alternative means of getting
super user access. A utility to test kernel system calls was also included to
ensure that there were no system calls that were blocked in a similar fashion
as Apple’s iOS.
Comparison between stock versions of Android and a partially SELinux
protected version of Android were made using the tool and results do show
that SELinux does offer some protection despite its infancy on Android.
58
89 See Appendix “11.9 Android Application to Test Permissions and Runtime.Exec”
8. Conclusion
It is unfortunate that the topics that security deals with especially in systems
and architecture design is so cross disciplinary, broad while being in-depth at
the same time for this to be easily concluded.
It is without a doubt that Android has its security issues. This does not just
stem from that fact that the platform is open source. Google’s policy and
philosophy towards their rapid platform growth with a small team in order to
catch up with Apple’s iOS devices comes at the cost of security.
While there are already security solutions on the market, this discourse and
real world examples prove that they are not enough to secure a platform that
will be used by many, most of which are not technically savvy. There is a need
for a holistic look towards security in general and sometimes looking at the
competitor platform for ideas does not hurt.
Others my detract and say that by implementing policies from a closed
system will destroy the open nature of the platform, it is worth a shot as these
policies are no different from those that can already be found on Linux
desktop distributions that also have open policies towards code.
In fact, it is the open source nature of Android that lets numerous security
solutions be experimented upon and code to be audited. The work by the NSA
and many others to improve the security of Android would not be possible if
the Android source code is there for anyone to tinker with.
However all these solutions are only as good as Google actually implementing
them. And while having numerous solutions are good, there has to be
standardization when it comes to security such that a proper policy that will
Open source security issues of the Android Platform
59
cater to the mass market can be designed. Security should not be complex as
it only creates more problems.
A call to action for OEM devices partners and custom ROM developers is
need to get everyone to start wanting to implement good security for Android
devices. And that call to action must be followed by an easy to implement and
genuinely intuitive and user accessible design.
Android has the potential to be one of the most secure operating systems on
the planet, but that would need the help of everyone in the Android
community. Otherwise, these open source security issues will still persist.
60
9. Recommendations
Just like BizTrust, there is a viable option in developing this idea of a holistic
security platform for Android much further. While BizTrust targets the
enterprise market, there is a larger one in the consumer space.
More should be done into looking at Mandatory Access Control on Linux.
Supporting the work to get SELinux on Android is a good start. In addition to
that, finding a way to map the security permissions that Dalvik requires to
the SELinux security context in an unobtrusive manner as much as possible
should be a top priority such that it is easy to integrate this system.
grsecurity is an untapped resource and should be full adapted to work for
Android. This would mean understanding the Linux kernel, grsecurity and
how it can be applied to the Android modified kernel. The tradeoffs however
are immeasurable due to the exploit mitigation techniques it provides.
Tools if not better tools to help administer these security features for users is
also another area to look towards to making this solution as holistic as
possible.
Open source security issues of the Android Platform
61
10. References
Clint, B. (2010, May 2). Android vp gundotra takes gloves off vs. apple at google i/o [Web log message]. Retrieved from http://www.eweek.com/c/a/Mobile-and-Wireless/Android-VP-Gundotra-Takes-Gloves-Off-Vs-Apple-at-Google-IO-455468/
Elgin , B. (2005, August 15). Google buys android for its mobile arsenal. Bloomberg Businessweek. Retrieved from http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm
Perez, S. (2011, August 15). Google / motorola deal doesn’t guarantee a “nexus droid” [Web log message]. Retrieved from http://techcrunch.com/2011/08/15/google-motorola-deal-doesnt-guarantee-a-nexus-droid/
Patel, N. (2011, May 12). How google controls android: digging deep into the skyhook filings [Web log message]. Retrieved from http://thisismynext.com/2011/05/12/google-android-skyhook-lawsuit-motorola-samsung/
Paul, R. (2009, February 23). Dream(sheep ): a developer's introduction to google android [Web log message]. Retrieved from http://arstechnica.com/open-source/reviews/2009/02/an-introduction-to-google-android-for-developers.ars
GoogleDevelopers. (Producer). (2011). Google i/o 2011: keynote day one. [Web Video]. Retrieved from http://www.youtube.com/watch?v=OxzucwjFEEs
Vassillis, A. (2011, June 02). From zero to boot: porting android to your arm platform [Web log message]. Retrieved from http://blogs.arm.com/software-enablement/498-from-zero-to-boot-porting-android-to-your-arm-platform/
Corbet, J. (2009, February 10). Wakelocks and the embedded problem [Web log message]. Retrieved from http://lwn.net/Articles/318611/
Corbet, J. (2009, February 18). From wakelocks to a real solution [Web log message]. Retrieved from http://lwn.net/Articles/319860/
Kroah-Hartman, G. (2010, December 09). Android and the linux kernel community [Web log message]. Retrieved from http://www.kroah.com/log/linux/android-kernel-problems.html
Vaughan-Nichols, S. J. (2011, August 18). Linus torvalds on android, the linux fork [Web log message]. Retrieved from http://www.zdnet.com/blog/open-source/linus-torvalds-on-android-the-linux-fork/9426
Linux standard base (lsb). (2010, April 29). Retrieved from http://www.linuxfoundation.org/collaborate/workgroups/lsb
Howto: unpack, edit, and re-pack boot images. In (2008). Retrieved from http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack,_Edit,_and_Re-Pack_Boot_Images
http://www.gnu.org/software/cpio/
Peter. (2010, December 28). Android 2.3 gingerbread uses ext4 file system, promises better dual-core performance [Web log message]. Retrieved from http://blog.gsmarena.com/android-2-3-gingerbread-uses-ext4-file-system-promises-better-dual-core-performance/
Smalley, S. (2011, May 11). Re: [android-kernel] froyo : ext4 instead of yaffs2 [Electronic mailing list message]. Retrieved
Open source security issues of the Android Platform
62
from http://www.mail-archive.com/[email protected]/msg03101.html
http://www.busybox.net
Cheri, Y., Schaller, A., & Wilson, G. (2007). Whitepaper: open source best practice. Retrieved from http://www.linuxfordevices.com/c/a/Linux-For-Devices-Articles/Whitepaper-Open-Source-Best-Practice/
Burnette, E. (2008, June 04). Patrick brady dissects android [Web log message]. Retrieved from http://www.zdnet.com/blog/burnette/patrick-brady-dissects-android/584
Castet, M. (2008, November 06). android thread library ported to uclibc [Electronic mailing list message]. Retrieved from http://www.mail-archive.com/[email protected]/msg02787.html
Linux interprocess communications. (1996, May 29). Retrieved from http://tldp.org/LDP/lpg/node7.html
Jsr 51: new i/o apis for the javatm platform. (2002, May 09). Retrieved from http://www.jcp.org/en/jsr/detail?id=51
Yueh, E. (2009, June 26) Android Bluetooth Introduction retrieved from http://www.slideshare.net/erinyueh/android-bluetooth-introduction
Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server
Yaghmor, K. (2011, March 09) Understanding the Android System Server presented at AnDevCon retrieved from http://www.slideshare.net/opersys/understanding-the-android-system-server
Printemps, G. (2008, September). Deep inside android.. Presentation presented at Openexpo 2008 - zurich. Retrieved from http://www.openexpo.ch/fileadmin/documents/2008Zuerich/Slides/33_Printemps.pdf
http://www.clojure.org
Gómez, D. S. (2011, February 04). Creating android applications with clojure, part 1 [Web log message]. Retrieved from http://www.deepbluelambda.org/programming/clojure/creating-android-applications-with-clojure
Garretson, R. (2010, June 04). google to ease android upgrade cycle [Web log message]. Retrieved from http://www.ciozone.com/index.php/Mobile-and-Wireless/Google-To-Ease-Android-Upgrade-Cycle.html
Sutton, M., Greene, A., & Amini, P. (2007). Fuzzing: brute force vulnerability discovery. Addison-Wesley.
Buchanan, E., Roemer, R., & Savage, S. (2008, August). Return-oriented programming: exploits without code injection. Retrieved from http://cseweb.ucsd.edu/~hovav/talks/blackhat08.html
Security and permissions. (n.d.). Retrieved from http://developer.android.com/guide/topics/security/security.html
Signing your applications. (2011, October 03). Retrieved from http://developer.android.com/guide/publishing/app-signing.html
Stericson. (2009, January 16). [how to] manuals for creating a theme view single post [Online forum comment]. Retrieved
63
from http://forum.xda-developers.com/showpost.php?p=3175518&postcount=2
bonsey. (2010, May 22). Java jdk,android sdk and resigning apk's [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=686341
Hu., V. C., Ferraiolo, D. F., & Kuhn, D. R. National Institute of Standards and Technology, Computer Security Division. (2006). Assessment of access control systems (Interagency Report 7316). Retrieved from http://csrc.nist.gov/publications/nistir/7316/NISTIR-7316.pdf
Manifest.permission. (2011, October 03). Retrieved from http://developer.android.com/reference/android/Manifest.permission.html
coderman. (2011, August 2011). Def con 19 - hackers get hacked! [Electronic mailing list message]. Retrieved from http://seclists.org/fulldisclosure/2011/Aug/76
Oberheide, J. (2010, May 28). When angry birds attack: android edition [Web log message]. Retrieved from http://jon.oberheide.org/blog/2011/05/28/when-angry-birds-attack-android-edition/
Oberheide, J. (2010, June 28). A peek inside the gtalkservice connection [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/28/a-peek-inside-the-gtalkservice-connection/
Oberheide, J. (2010, June 25). Remote kill and install on google android [Web log message]. Retrieved from http://jon.oberheide.org/blog/2010/06/25/remote-kill-and-install-on-google-android/
Oberheide, J. (2011, March 07). How i almost won pwn2own via xss [Web log message]. Retrieved from http://
jon.oberheide.org/blog/2011/03/07/how-i-almost-won-pwn2own-via-xss/
Neystadt, J. (2008, February). Automated penetration testing with white-box fuzzing. Retrieved from http://msdn.microsoft.com/en-us/library/cc162782.aspx
http://www.htcdev.com/bootloader
Chou, P. (2011, May 27). Statement from htc ceo [Facebook message]. Retrieved from https://www.facebook.com/HTC/posts/10150307320018084
Ziegler, C. (2010, July 16). Motorola responds to droid x bootloader controversy, says efuse isn't there to break the phone [Web log message]. Retrieved from http://www.engadget.com/2010/07/16/motorola-responds-to-droid-x-bootloader-controversy-says-efuse/
"cellulararrest". (2009, December 09). [droid] root instructions (updated) [Online forum comment]. Retrieved from http://forum.xda-developers.com/showthread.php?t=597175
Rollings, M. (2010, January 17). Android: requesting root access in your app [Web log message]. Retrieved from http://www.stealthcopter.com/blog/2010/01/android-requesting-root-access-in-your-app/
Passeri, P. (2011, August 11). One year of android malware (full list) [Web log message]. Retrieved from https://paulsparrows.wordpress.com/2011/08/11/one-year-of-android-malware-full-list/
Mcafee labs (2011). Mcafee threats report: second quarter 2011. Retrieved from http://www.mcafee.com/us/resources/reports/rp-quarterly-threat-q2-2011.pdf
64
Kevin. (2011, March 01). Update: security alert: droiddream malware found in official android market [Web log message]. Retrieved from http://blog.mylookout.com/2011/03/security-alert-malware-found-in-official-android-market-droiddream/
Android.geinimi. (2011, January 01). Retrieved from http://www.symantec.com/security_response/writeup.jsp?docid=2011-010111-5403-99&tabid=2
Lineberry, A. M. (2010, August 25). Reversing latest exploid release [Web log message]. Retrieved from http://dtors.org/2010/08/25/reversing-latest-exploid-release/
Russakovskii, A. (2011, October 05). Massive security vulnerability in htc android devices (evo 3d, 4g, thunderbolt, others) exposes phone numbers, gps, sms, emails addresses, much more [Web log message]. Retrieved from http://www.androidpolice.com/2011/10/01/massive-security-vulnerability-in-htc-android-devices-evo-3d-4g-thunderbolt-others-exposes-phone-numbers-gps-sms-emails-addresses-much-more/
Case, J. (2011, April 15). [updated] exclusive: vulnerability in skype for android is exposing your name, phone number, chat logs, and a lot more [Web log message]. Retrieved from http://www.androidpolice.com/2011/04/14/exclusive-vulnerability-in-skype-for-android-is-exposing-your-name-phone-number-chat-logs-and-a-lot-more/
Loscocco, P. A., Smalley, S. D., Muckelbauer, P. A., Taylor, R. C., Turner, J. S., & Farrell, J. F. (1998, October). The inevitability of failure: the flawed assumption of security in modern computing environments. Paper presented at 21st national information systems security conference. Retrieved from http://www.nsa.gov/research/_files/selinux/papers/inevit-abs.shtml
"Personal computers (per capita) by country", World Development Indicators database. Retrieved from http://www.NationMaster.com/graph/med_per_com_percap-media-personal-computers-per-capita
"Mobile phones by country", International Telecommunication Union. Retrieved from http://www.NationMaster.com/graph/med_mob_pho-media-mobile-phones
Worthington, D. (2011, March 28). My mom reviews the ipad, her first computer [Web log message]. Retrieved from http://technologizer.com/2011/03/28/my-mom-reviews-the-ipad-her-first-computer/
http://radian.org/
Krstić, I. (2007). OLPC Bitfrost.Olpc. Retrieved from http://wiki.laptop.org/go/OLPC_Bitfrost
Fisher, D. (2011, July 21). Apple revamps security in os x lion [Web log message]. Retrieved from https://threatpost.com/en_us/blogs/apple-revamps-security-os-x-lion-072111
http://linux-vserver.org/
Vervloesem, K. (2010, May 05). Qubes: security by virtualization [Web log message]. Retrieved from http://lwn.net/Articles/385213/
http://qubes-os.org/
Smalley, S. National Security Agency, Trust Mechanisms (R2X). (2011). The case for se android. Retrieved from http://selinuxproject.org/~jmorris/lss2011_slides/caseforseandroid.pdf
65
UNGERLEIDER, N. (2011, October 10). The most secure android phone, ever [Web log message]. Retrieved from http://www.fastcompany.com/1786472/most-secure-android-phone-ever-blackberry-headache?partner=gnews
Nachenberg, C. (2011). A window into mobile device security. Retrieved from http://www.symantec.com/content/en/us/about/media/pdfs/symc_mobile_device_security_june2011.pdf?om_ext_cid=biz_socmed_twitter_facebook_marketwire_linkedin_2011Jun_worldwide_mobilesecuritywp
http://selinuxproject.org/
http://www.trustedbsd.org
http://www.grsecurity.net
http://pax.grsecurity.net/
http://pax.grsecurity.net/docs/
Kane, D. (2009, August 11). Computer scientists take over electronic voting machine with new programming technique [Web log message]. Retrieved from http://www.sciencedaily.com/releases/2009/08/090810161902.htm
c0ntex. (n.d.). Bypassing non-executable-stack during exploitation using return-to-libc [Electronic mailing list message]. Retrieved from http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf
Vaughan-Nichols, S. J. (2010, September 07). Android/linux kernel fight continues [Web log message]. Retrieved from http://blogs.computerworld.com/16900/android_linux_kernel_fight_continues
http://mirrors.muarf.org/
grsecurity/test/
66
11. Appendix
11.1 Android /system/bin
# ls -l-rwxr-xr-x root shell 191 2010-11-25 05:42 am-rwxr-xr-x root shell 5720 2010-11-25 05:42 app_process-rwxr-xr-x root shell 49924 2011-05-04 02:10 applypatch-rwxr-xr-x root shell 5292 2010-11-25 05:42 bluetoothd-rwxr-xr-x root shell 199 2010-11-25 05:42 bmgr-rwxr-xr-x root shell 23160 2010-11-25 05:42 bootanimation-rwxr-xr-x root shell 10116 2010-11-25 05:42 brcm_patchram_plus-rwxr-xr-x root shell 5556 2010-11-25 05:42 bugreportlrwxr-xr-x root shell 2010-11-30 07:30 cat -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 chmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 chown -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 cmp -> toolbox-rwxr-xr-x root shell 5520 2011-05-04 02:10 dalvikvmlrwxr-xr-x root shell 2010-11-30 07:30 date -> toolbox-rwxr-xr-x root shell 109504 2011-05-04 02:10 dbus-daemonlrwxr-xr-x root shell 2010-11-30 07:30 dd -> toolbox-rwxr-xr-x root shell 18112 2011-05-04 02:10 debuggerd-rwxr-xr-x root shell 9796 2011-05-04 02:10 dexoptlrwxr-xr-x root shell 2010-11-30 07:30 df -> toolbox-rwxr-xr-x root shell 44596 2011-05-04 02:10 dhcpcdlrwxr-xr-x root shell 2010-11-30 07:30 dmesg -> toolbox-rwxr-xr-x root shell 108820 2011-05-04 02:10 dnsmasq-rwxr-xr-x root shell 34544 2010-11-25 05:42 dumpstate-rwxr-xr-x root shell 9812 2010-11-25 05:42 dumpsys-rwxr-xr-x root shell 5548 2010-11-25 05:42 dvz-rwxr-xr-x root shell 22640 2011-05-04 02:10 fsck_msdoslrwxr-xr-x root shell 2010-11-30 07:30 getevent -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 getprop -> toolbox-rwxr-xr-x root shell 5604 2011-05-04 02:10 gzip-rwxr-xr-x root shell 23284 2011-05-04 02:10 hciattachlrwxr-xr-x root shell 2010-11-30 07:30 hd -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 id -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ifconfig -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 iftop -> toolbox-rwxr-xr-x root shell 194 2010-11-25 05:42 ime-rwxr-xr-x root shell 201 2010-11-25 05:42 inputlrwxr-xr-x root shell 2010-11-30 07:30 insmod -> toolbox-rwxr-xr-x root shell 22420 2011-05-04 02:10 installdlrwxr-xr-x root shell 2010-11-30 07:30 ioctl -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ionice -> toolbox-rwxr-xr-x root shell 100916 2011-05-04 02:10 iptables-rwxr-xr-x root shell 10112 2011-05-04 02:10 keystorelrwxr-xr-x root shell 2010-11-30 07:30 kill -> toolbox-rwxr-xr-x root shell 39416 2011-05-04 02:10 linkerlrwxr-xr-x root shell 2010-11-30 07:30 ln -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 log -> toolbox-rwxr-xr-x root shell 13952 2011-05-04 02:10 logcat-rwxr-xr-x root shell 9760 2011-05-04 02:10 logwrapperlrwxr-xr-x root shell 2010-11-30 07:30 ls -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 lsmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 lsof -> toolbox-rwxr-xr-x root shell 5504 2010-11-25 05:42 make_ext4fs-rwxr-xr-x root shell 5488 2010-11-25 05:42 mediaserverlrwxr-xr-x root shell 2010-11-30 07:30 mkdir -> toolbox-rwxr-xr-x root shell 205 2010-11-25 05:42 monkeylrwxr-xr-x root shell 2010-11-30 07:30 mount -> toolbox-rwxr-xr-x root shell 18308 2011-05-04 02:10 mtpdlrwxr-xr-x root shell 2010-11-30 07:30 mv -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 nandread -> toolbox-rwxr-xr-x root shell 5552 2010-11-25 05:42 ndc-rwxr-s--- root inet 5660 2011-05-04 02:10 netcfg-rwxr-xr-x root shell 31172 2011-05-04 02:10 netd
Open source security issues of the Android Platform
67
lrwxr-xr-x root shell 2010-11-30 07:30 netstat -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 newfs_msdos -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 notify -> toolbox-rwxr-xr-x root shell 32600 2011-05-04 02:10 omx_tests-rwxr-xr-x root shell 18692 2010-11-25 05:42 pand-rwxr-sr-x root net_raw 26720 2011-05-04 02:10 ping-rwxr-xr-x root shell 191 2010-11-25 05:42 pm-rwxr-xr-x root shell 139540 2011-05-04 02:10 pppdlrwxr-xr-x root shell 2010-11-30 07:30 printenv -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 ps -> toolbox-rwxr-xr-x root shell 142516 2011-05-04 02:10 racoonlrwxr-xr-x root shell 2010-11-30 07:30 reboot -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 renice -> toolbox-rwxr-xr-x root shell 9808 2011-05-04 02:10 rildlrwxr-xr-x root shell 2010-11-30 07:30 rm -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 rmdir -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 rmmod -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 route -> toolbox-rwsr-s--- root shell 59848 2011-05-04 02:10 run-as-rwxr-xr-x root shell 5392 2010-11-25 05:42 schedtestlrwxr-xr-x root shell 2010-11-30 07:30 schedtop -> toolbox-rwxr-xr-x root shell 9748 2010-11-25 05:42 sdcard-rwxr-xr-x root shell 42404 2010-11-25 05:42 sdptoollrwxr-xr-x root shell 2010-11-30 07:30 sendevent -> toolbox-rwxr-xr-x root shell 9860 2010-11-25 05:42 service-rwxr-xr-x root shell 9940 2011-05-04 02:10 servicemanagerlrwxr-xr-x root shell 2010-11-30 07:30 setconsole -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 setprop -> toolbox-rwxr-xr-x root shell 5564 2010-11-25 05:42 setup_fs-rwxr-xr-x root shell 82840 2011-05-04 02:10 shlrwxr-xr-x root shell 2010-11-30 07:30 sleep -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 smd -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 start -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 stop -> toolbox-rwxr-xr-x root shell 5456 2011-05-04 02:10 surfaceflinger-rwxr-xr-x root shell 192 2010-11-25 05:42 svclrwxr-xr-x root shell 2010-11-30 07:30 sync -> toolbox-rwxr-xr-x root shell 5472 2010-11-25 05:42 system_server-rwxr-xr-x root shell 67956 2011-05-04 02:10 tc-rwxr-xr-x root shell 81544 2011-05-04 02:10 toolboxlrwxr-xr-x root shell 2010-11-30 07:30 top -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 umount -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 uptime -> toolbox-rwxr-xr-x root shell 5552 2010-11-25 05:42 vdclrwxr-xr-x root shell 2010-11-30 07:30 vmstat -> toolbox-rwxr-xr-x root shell 51700 2011-05-04 02:10 voldlrwxr-xr-x root shell 2010-11-30 07:30 watchprops -> toolboxlrwxr-xr-x root shell 2010-11-30 07:30 wipe -> toolbox-rwxr-xr-x root shell 291876 2011-05-04 02:10 wpa_supplicant-rwsr-sr-x root root 22228 2011-09-29 21:16 su-rwxr-xr-x root shell 24120 2011-03-23 19:51 sqlite3drwxrwxrwx root root 2011-09-29 21:40 failsafe
68
11.2 Ubuntu /bin
jeremy@jeremy-ubuntu:/bin$ ls -ltotal 8108-rwxr-xr-x 1 root root 954896 2011-04-01 05:20 bash-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bunzip2-rwxr-xr-x 1 root root 1964728 2011-02-23 11:30 busybox-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bzcatlrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzcmp -> bzdiff-rwxr-xr-x 1 root root 2140 2011-02-21 00:13 bzdifflrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzegrep -> bzgrep-rwxr-xr-x 1 root root 4874 2011-02-21 00:13 bzexelrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzfgrep -> bzgrep-rwxr-xr-x 1 root root 3642 2011-02-21 00:13 bzgrep-rwxr-xr-x 1 root root 31112 2011-02-21 00:13 bzip2-rwxr-xr-x 1 root root 10336 2011-02-21 00:13 bzip2recoverlrwxrwxrwx 1 root root 6 2011-07-31 02:47 bzless -> bzmore-rwxr-xr-x 1 root root 1297 2011-02-21 00:13 bzmore-rwxr-xr-x 1 root root 47696 2011-02-23 22:24 cat-rwxr-xr-x 1 root root 55864 2011-02-23 22:24 chgrp-rwxr-xr-x 1 root root 51704 2011-02-23 22:24 chmod-rwxr-xr-x 1 root root 55880 2011-02-23 22:24 chown-rwxr-xr-x 1 root root 10392 2011-03-18 07:47 chvt-rwxr-xr-x 1 root root 117808 2011-02-23 22:24 cp-rwxr-xr-x 1 root root 137232 2011-02-24 01:49 cpio-rwxr-xr-x 1 root root 109736 2010-11-15 16:34 dash-rwxr-xr-x 1 root root 55832 2011-02-23 22:24 date-rwxr-xr-x 1 root root 10464 2011-07-23 01:05 dbus-cleanup-sockets-rwxr-xr-x 1 root root 351448 2011-07-23 01:05 dbus-daemon-rwxr-xr-x 1 root root 10376 2011-07-23 01:05 dbus-uuidgen-rwxr-xr-x 1 root root 51840 2011-02-23 22:24 dd-rwxr-xr-x 1 root root 64208 2011-02-23 22:24 df-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 dir-rwxr-xr-x 1 root root 10368 2011-03-21 16:28 dmesg-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 dnsdomainname-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 domainname-rwxr-xr-x 1 root root 82152 2011-03-18 07:47 dumpkeys-rwxr-xr-x 1 root root 26968 2011-02-23 22:24 echo-rwxr-xr-x 1 root root 47552 2010-10-30 00:45 ed-rwxr-xr-x 1 root root 126240 2010-11-18 12:09 egrep-rwxr-xr-x 1 root root 22856 2011-02-23 22:24 false-rwxr-xr-x 1 root root 10408 2011-03-18 07:47 fgconsole-rwxr-xr-x 1 root root 85088 2010-11-18 12:09 fgrep-rwxr-xr-x 1 root root 31680 2010-10-16 00:47 fuser-rwsr-xr-x 1 root root 31320 2011-02-11 05:03 fusermount-rwxr-xr-x 1 root root 126272 2010-11-18 12:09 grep-rwxr-xr-x 1 root root 63 2010-08-17 16:43 gunzip-rwxr-xr-x 1 root root 5874 2010-08-17 16:43 gzexe-rwxr-xr-x 1 root root 64168 2010-08-17 16:43 gzip-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 hostname-rwxr-xr-x 1 root root 5564 2011-04-21 06:56 init-checkconf-rwxr-xr-x 1 root root 16005 2011-04-21 06:56 initctl2dot-rwxr-xr-x 1 root root 234768 2010-10-15 20:45 ip-rwxr-xr-x 1 root root 10400 2011-03-18 07:47 kbd_mode-rwxr-xr-x 1 root root 18736 2011-04-07 23:36 kill-rwxr-xr-x 1 root root 149496 2009-11-05 16:52 less-rwxr-xr-x 1 root root 10504 2009-11-05 16:52 lessecholrwxrwxrwx 1 root root 8 2011-07-31 02:47 lessfile -> lesspipe-rwxr-xr-x 1 root root 15840 2009-11-05 16:52 lesskey-rwxr-xr-x 1 root root 6947 2009-11-05 16:51 lesspipe-rwxr-xr-x 1 root root 47680 2011-02-23 22:24 ln-rwxr-xr-x 1 root root 111288 2011-03-18 07:47 loadkeys-rwxr-xr-x 1 root root 44928 2011-02-21 08:18 login-rwxr-xr-x 1 root root 57000 2010-09-16 08:23 lowntfs-3g-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 ls-rwxr-xr-x 1 root root 6088 2011-04-01 22:05 lsmod-rwxr-xr-x 1 root root 47624 2011-02-23 22:24 mkdir-rwxr-xr-x 1 root root 31112 2011-02-23 22:24 mknod-rwxr-xr-x 1 root root 35352 2011-02-23 22:24 mktemp-rwxr-xr-x 1 root root 35448 2011-03-21 16:28 more-rwsr-xr-x 1 root root 82224 2011-03-21 16:28 mount-rwxr-xr-x 1 root root 10264 2011-03-29 04:21 mountpoint
69
lrwxrwxrwx 1 root root 20 2011-07-31 02:47 mt -> /etc/alternatives/mt-rwxr-xr-x 1 root root 68712 2011-02-24 01:49 mt-gnu-rwxr-xr-x 1 root root 109584 2011-02-23 22:24 mv-rwxr-xr-x 1 root root 191960 2010-12-04 04:32 nanolrwxrwxrwx 1 root root 20 2011-07-31 02:47 nc -> /etc/alternatives/nc-rwxr-xr-x 1 root root 31152 2011-01-05 04:23 nc.openbsdlrwxrwxrwx 1 root root 24 2011-07-31 02:47 netcat -> /etc/alternatives/netcat-rwxr-xr-x 1 root root 120184 2010-07-02 15:28 netstat-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 nisdomainname-rwxr-xr-x 1 root root 52800 2010-09-16 08:23 ntfs-3g-rwxr-xr-x 1 root root 10368 2010-09-16 08:23 ntfs-3g.probe-rwxr-xr-x 1 root root 55816 2010-09-16 08:23 ntfs-3g.secaudit-rwxr-xr-x 1 root root 14576 2010-09-16 08:23 ntfs-3g.usermaplrwxrwxrwx 1 root root 6 2011-07-31 02:47 open -> openvt-rwxr-xr-x 1 root root 14688 2011-03-18 07:47 openvtlrwxrwxrwx 1 root root 14 2011-07-31 02:47 pidof -> /sbin/killall5-rwsr-xr-x 1 root root 35680 2010-11-15 16:11 ping-rwsr-xr-x 1 root root 40248 2010-11-15 16:11 ping6-rwxr-xr-x 1 root root 35360 2011-04-27 05:31 plymouth-rwxr-xr-x 1 root root 31560 2011-04-27 05:31 plymouth-upstart-bridge-rwxr-xr-x 1 root root 101184 2011-04-07 23:36 ps-rwxr-xr-x 1 root root 31200 2011-02-23 22:24 pwdlrwxrwxrwx 1 root root 4 2011-07-31 02:47 rbash -> bash-rwxr-xr-x 1 root root 35272 2011-02-23 22:24 readlink-rwxr-xr-x 1 root root 55872 2011-02-23 22:24 rm-rwxr-xr-x 1 root root 39320 2011-02-23 22:24 rmdirlrwxrwxrwx 1 root root 4 2011-07-31 02:47 rnano -> nano-rwxr-xr-x 1 root root 15048 2011-01-20 23:44 run-parts-rwxr-xr-x 1 root root 69024 2010-11-16 18:14 sed-rwxr-xr-x 1 root root 39744 2011-03-18 07:47 setfont-rwxr-xr-x 1 root root 12052 2011-04-21 01:02 setupconlrwxrwxrwx 1 root root 4 2011-07-31 02:47 sh -> dashlrwxrwxrwx 1 root root 4 2011-07-31 02:47 sh.distrib -> bash-rwxr-xr-x 1 root root 26984 2011-02-23 22:24 sleeplrwxrwxrwx 1 root root 7 2011-07-31 02:47 static-sh -> busybox-rwxr-xr-x 1 root root 63992 2011-02-23 22:24 stty-rwsr-xr-x 1 root root 36832 2011-02-21 08:18 su-rwxr-xr-x 1 root root 22872 2011-02-23 22:24 sync-rwxr-xr-x 1 root root 10488 2011-03-21 16:28 tailf-rwxr-xr-x 1 root root 311888 2010-12-07 18:10 tar-rwxr-xr-x 1 root root 10312 2011-01-20 23:44 tempfile-rwxr-xr-x 1 root root 47640 2011-02-23 22:24 touch-rwxr-xr-x 1 root root 22856 2011-02-23 22:24 true-rwxr-xr-x 1 root root 14656 2011-02-11 05:03 ulockmgr_server-rwsr-xr-x 1 root root 56616 2011-03-21 16:28 umount-rwxr-xr-x 1 root root 27016 2011-02-23 22:24 uname-rwxr-xr-x 1 root root 63 2010-08-17 16:43 uncompress-rwxr-xr-x 1 root root 2762 2011-03-18 07:47 unicode_start-rwxr-xr-x 1 root root 105776 2011-02-23 22:24 vdir-rwxr-xr-x 1 root root 6200 2011-02-23 23:58 vmmouse_detect-rwxr-xr-x 1 root root 946 2011-01-20 23:44 which-rwxr-xr-x 1 root root 14688 2010-11-17 23:51 ypdomainname-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zcat-rwxr-xr-x 1 root root 69 2010-08-17 16:43 zcmp-rwxr-xr-x 1 root root 4424 2010-08-17 16:43 zdiff-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zegrep-rwxr-xr-x 1 root root 64 2010-08-17 16:43 zfgrep-rwxr-xr-x 1 root root 2015 2010-08-17 16:43 zforce-rwxr-xr-x 1 root root 5597 2010-08-17 16:43 zgrep-rwxr-xr-x 1 root root 1733 2010-08-17 16:43 zless-rwxr-xr-x 1 root root 2416 2010-08-17 16:43 zmore-rwxr-xr-x 1 root root 4952 2010-08-17 16:43 znew
70
11.3 Android Filesystem Configuration Header
/* * Copyright (C) 2007 The Android Open Source Project * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */
/* This file is used to define the properties of the filesystem** images generated by build tools (mkbootfs and mkyaffs2image) and** by the device side of adb.*/
#ifndef _ANDROID_FILESYSTEM_CONFIG_H_#define _ANDROID_FILESYSTEM_CONFIG_H_
#include <string.h>#include <sys/stat.h>#include <sys/types.h>
/* This is the master Users and Groups config for the platform.** DO NOT EVER RENUMBER.*/
#define AID_ROOT 0 /* traditional unix root user */
#define AID_SYSTEM 1000 /* system server */
#define AID_RADIO 1001 /* telephony subsystem, RIL */#define AID_BLUETOOTH 1002 /* bluetooth subsystem */#define AID_GRAPHICS 1003 /* graphics devices */#define AID_INPUT 1004 /* input devices */#define AID_AUDIO 1005 /* audio devices */#define AID_CAMERA 1006 /* camera devices */#define AID_LOG 1007 /* log devices */#define AID_COMPASS 1008 /* compass device */#define AID_MOUNT 1009 /* mountd socket */#define AID_WIFI 1010 /* wifi subsystem */#define AID_ADB 1011 /* android debug bridge (adbd) */#define AID_INSTALL 1012 /* group for installing packages */#define AID_MEDIA 1013 /* mediaserver process */#define AID_DHCP 1014 /* dhcp client */#define AID_SDCARD_RW 1015 /* external storage write access */#define AID_VPN 1016 /* vpn system */#define AID_KEYSTORE 1017 /* keystore subsystem */#define AID_USB 1018 /* USB devices */#define AID_DRM 1019 /* DRM server */#define AID_DRMIO 1020 /* DRM IO server */#define AID_GPS 1021 /* GPS daemon */#define AID_UNUSED1 1022 /* deprecated, DO NOT USE */#define AID_RFU1 1023 /* RFU */#define AID_RFU2 1024 /* RFU */#define AID_NFC 1025 /* nfc subsystem */
#define AID_SHELL 2000 /* adb and debug shell user */#define AID_CACHE 2001 /* cache access */#define AID_DIAG 2002 /* access to diagnostic resources */
/* The 3000 series are intended for use as supplemental group id's only. * They indicate special Android capabilities that the kernel is aware of. */#define AID_NET_BT_ADMIN 3001 /* bluetooth: create any socket */#define AID_NET_BT 3002 /* bluetooth: create sco, rfcomm or l2cap sockets */
71
#define AID_INET 3003 /* can create AF_INET and AF_INET6 sockets */#define AID_NET_RAW 3004 /* can create raw INET sockets */#define AID_NET_ADMIN 3005 /* can configure interfaces and routing tables. */
#define AID_MISC 9998 /* access to misc storage */#define AID_NOBODY 9999
#define AID_APP 10000 /* first app user */
#if !defined(EXCLUDE_FS_CONFIG_STRUCTURES)struct android_id_info { const char *name; unsigned aid;};
static const struct android_id_info android_ids[] = { { "root", AID_ROOT, }, { "system", AID_SYSTEM, }, { "radio", AID_RADIO, }, { "bluetooth", AID_BLUETOOTH, }, { "graphics", AID_GRAPHICS, }, { "input", AID_INPUT, }, { "audio", AID_AUDIO, }, { "camera", AID_CAMERA, }, { "log", AID_LOG, }, { "compass", AID_COMPASS, }, { "mount", AID_MOUNT, }, { "wifi", AID_WIFI, }, { "dhcp", AID_DHCP, }, { "adb", AID_ADB, }, { "install", AID_INSTALL, }, { "media", AID_MEDIA, }, { "drm", AID_DRM, }, { "drmio", AID_DRMIO, }, { "nfc", AID_NFC, }, { "shell", AID_SHELL, }, { "cache", AID_CACHE, }, { "diag", AID_DIAG, }, { "net_bt_admin", AID_NET_BT_ADMIN, }, { "net_bt", AID_NET_BT, }, { "sdcard_rw", AID_SDCARD_RW, }, { "vpn", AID_VPN, }, { "keystore", AID_KEYSTORE, }, { "usb", AID_USB, }, { "gps", AID_GPS, }, { "inet", AID_INET, }, { "net_raw", AID_NET_RAW, }, { "net_admin", AID_NET_ADMIN, }, { "misc", AID_MISC, }, { "nobody", AID_NOBODY, },};
#define android_id_count \ (sizeof(android_ids) / sizeof(android_ids[0])) struct fs_path_config { unsigned mode; unsigned uid; unsigned gid; const char *prefix;};
/* Rules for directories.** These rules are applied based on "first match", so they** should start with the most specific path and work their** way up to the root.*/
static struct fs_path_config android_dirs[] = { { 00770, AID_SYSTEM, AID_CACHE, "cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/app" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/app-private" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/dalvik-cache" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data/data" },
72
{ 00771, AID_SHELL, AID_SHELL, "data/local/tmp" }, { 00771, AID_SHELL, AID_SHELL, "data/local" }, { 01771, AID_SYSTEM, AID_MISC, "data/misc" }, { 00770, AID_DHCP, AID_DHCP, "data/misc/dhcp" }, { 00771, AID_SYSTEM, AID_SYSTEM, "data" }, { 00750, AID_ROOT, AID_SHELL, "sbin" }, { 00755, AID_ROOT, AID_SHELL, "system/bin" }, { 00755, AID_ROOT, AID_SHELL, "system/vendor" }, { 00755, AID_ROOT, AID_SHELL, "system/xbin" }, { 00755, AID_ROOT, AID_ROOT, "system/etc/ppp" }, { 00777, AID_ROOT, AID_ROOT, "sdcard" }, { 00755, AID_ROOT, AID_ROOT, 0 },};
/* Rules for files.** These rules are applied based on "first match", so they** should start with the most specific path and work their** way up to the root. Prefixes ending in * denotes wildcard** and will allow partial matches.*/static struct fs_path_config android_files[] = { { 00440, AID_ROOT, AID_SHELL, "system/etc/init.goldfish.rc" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.goldfish.sh" }, { 00440, AID_ROOT, AID_SHELL, "system/etc/init.trout.rc" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.ril" }, { 00550, AID_ROOT, AID_SHELL, "system/etc/init.testmenu" }, { 00550, AID_DHCP, AID_SHELL, "system/etc/dhcpcd/dhcpcd-run-hooks" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/dbus.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/main.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/input.conf" }, { 00440, AID_BLUETOOTH, AID_BLUETOOTH, "system/etc/bluetooth/audio.conf" }, { 00444, AID_NET_BT, AID_NET_BT, "system/etc/bluetooth/blacklist.conf" }, { 00640, AID_SYSTEM, AID_SYSTEM, "system/etc/bluetooth/auto_pairing.conf" }, { 00444, AID_RADIO, AID_AUDIO, "system/etc/AudioPara4.csv" }, { 00555, AID_ROOT, AID_ROOT, "system/etc/ppp/*" }, { 00555, AID_ROOT, AID_ROOT, "system/etc/rc.*" }, { 00644, AID_SYSTEM, AID_SYSTEM, "data/app/*" }, { 00644, AID_SYSTEM, AID_SYSTEM, "data/app-private/*" }, { 00644, AID_APP, AID_APP, "data/data/*" }, /* the following two files are INTENTIONALLY set-gid and not set-uid. * Do not change. */ { 02755, AID_ROOT, AID_NET_RAW, "system/bin/ping" }, { 02750, AID_ROOT, AID_INET, "system/bin/netcfg" }, !/* the following five files are INTENTIONALLY set-uid, but they! * are NOT included on user builds. */ { 06755, AID_ROOT, AID_ROOT, "system/xbin/su" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/librank" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/procrank" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/procmem" }, { 06755, AID_ROOT, AID_ROOT, "system/xbin/tcpdump" }, { 04770, AID_ROOT, AID_RADIO, "system/bin/pppd-ril" },!!/* the following file is INTENTIONALLY set-uid, and IS included!! * in user builds. */ { 06750, AID_ROOT, AID_SHELL, "system/bin/run-as" }, { 00755, AID_ROOT, AID_SHELL, "system/bin/*" }, { 00755, AID_ROOT, AID_SHELL, "system/xbin/*" }, { 00755, AID_ROOT, AID_SHELL, "system/vendor/bin/*" }, { 00750, AID_ROOT, AID_SHELL, "sbin/*" }, { 00755, AID_ROOT, AID_ROOT, "bin/*" }, { 00750, AID_ROOT, AID_SHELL, "init*" }, { 00644, AID_ROOT, AID_ROOT, 0 },};
static inline void fs_config(const char *path, int dir, unsigned *uid, unsigned *gid, unsigned *mode){ struct fs_path_config *pc; int plen; pc = dir ? android_dirs : android_files; plen = strlen(path); for(; pc->prefix; pc++){ int len = strlen(pc->prefix);
73
if (dir) { if(plen < len) continue; if(!strncmp(pc->prefix, path, len)) break; continue; } /* If name ends in * then allow partial matches. */ if (pc->prefix[len -1] == '*') { if(!strncmp(pc->prefix, path, len - 1)) break; } else if (plen == len){ if(!strncmp(pc->prefix, path, len)) break; } } *uid = pc->uid; *gid = pc->gid; *mode = (*mode & (~07777)) | pc->mode; #if 0 fprintf(stderr,"< '%s' '%s' %d %d %o >\n", path, pc->prefix ? pc->prefix : "", *uid, *gid, *mode);#endif}#endif#endif
74
11.4 New files added to Android Kernel
jeremy@jeremy-ubuntu:~$ diff -rq linux-stable samsung | grep "Only in"Only in samsung/Documentation: android.txtOnly in samsung/arch/arm/common: fiq_debugger.cOnly in samsung/arch/arm/common: fiq_debugger_ringbuf.hOnly in samsung/arch/arm/common: fiq_glue.SOnly in samsung/arch/arm/common: fiq_glue_setup.cOnly in samsung/arch/arm/configs: herring_defconfigOnly in samsung/arch/arm/include/asm: fiq_debugger.hOnly in samsung/arch/arm/include/asm: fiq_glue.hOnly in samsung/arch/arm/mach-s5pv210: adc.cOnly in samsung/arch/arm/mach-s5pv210: coresight.cOnly in samsung/arch/arm/mach-s5pv210: cpu-freq.cOnly in samsung/arch/arm/mach-s5pv210: cpuidle.cOnly in samsung/arch/arm/mach-s5pv210: dev-cpufreq.cOnly in samsung/arch/arm/mach-s5pv210: dev-fiqdbg.cOnly in samsung/arch/arm/mach-s5pv210: dev-herring-phone.cOnly in samsung/arch/arm/mach-s5pv210: herring-btlpm.cOnly in samsung/arch/arm/mach-s5pv210: herring-panel.cOnly in samsung/arch/arm/mach-s5pv210: herring-rfkill.cOnly in samsung/arch/arm/mach-s5pv210: herring-touchkey-led.cOnly in samsung/arch/arm/mach-s5pv210: herring-vibrator.cOnly in samsung/arch/arm/mach-s5pv210: herring-watchdog.cOnly in samsung/arch/arm/mach-s5pv210: herring.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: adc.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: battery.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: cpu-freq-v210.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: gpio-herring.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: media.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: param.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: pm-core.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: power-domain.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-adc.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-audss.hOnly in samsung/arch/arm/mach-s5pv210/include/mach: regs-mem.hOnly in samsung/arch/arm/mach-s5pv210: mach-herring.cOnly in samsung/arch/arm/mach-s5pv210: pm.cOnly in samsung/arch/arm/mach-s5pv210: power-domain.cOnly in samsung/arch/arm/mach-s5pv210: setup-csis.cOnly in samsung/arch/arm/mach-s5pv210: setup-fb.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc0.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc1.cOnly in samsung/arch/arm/mach-s5pv210: setup-fimc2.cOnly in samsung/arch/arm/mach-s5pv210: sleep.SOnly in samsung/arch/arm/plat-s5p: bootmem.cOnly in samsung/arch/arm/plat-s5p: dev-csis.cOnly in samsung/arch/arm/plat-s5p: dev-mfc.cOnly in samsung/arch/arm/plat-s5p: devs.cOnly in samsung/arch/arm/plat-s5p: hr-time-rtc.cOnly in samsung/arch/arm/plat-s5p/include/plat: csis.hOnly in samsung/arch/arm/plat-s5p/include/plat: fb.hOnly in samsung/arch/arm/plat-s5p/include/plat: fimc.hOnly in samsung/arch/arm/plat-s5p/include/plat: irq-eint-group.hOnly in samsung/arch/arm/plat-s5p/include/plat: irq-pm.hOnly in samsung/arch/arm/plat-s5p/include/plat: jpeg.hOnly in samsung/arch/arm/plat-s5p/include/plat: media.hOnly in samsung/arch/arm/plat-s5p/include/plat: mfc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-csis.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-fb.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-fimc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-iis.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-ipc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-keypad.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-mfc.hOnly in samsung/arch/arm/plat-s5p/include/plat: regs-systimer.hOnly in samsung/arch/arm/plat-s5p: irq-eint-group.cOnly in samsung/arch/arm/plat-s5p: irq-pm.cOnly in samsung/arch/arm/plat-s5p: pm.cOnly in samsung/arch/arm/plat-s5p: setup-mfc.cOnly in samsung/arch/arm/plat-s5p: systimer-s5p.cOnly in samsung/arch/arm/plat-samsung: dev-hsmmc3.c
75
Only in samsung/arch/arm/plat-samsung/include/plat: regs-otg.hOnly in samsung/drivers/char: dcc_tty.cOnly in samsung/drivers/char: s3c_mem.cOnly in samsung/drivers/char: s3c_mem.hOnly in samsung/drivers/gpu: pvrOnly in samsung/drivers/input/keyboard: cypress-touchkey-firmware.cOnly in samsung/drivers/input/keyboard: cypress-touchkey-firmware.hOnly in samsung/drivers/input/keyboard: cypress-touchkey.cOnly in samsung/drivers/input: keyreset.cOnly in samsung/drivers/input/misc: gp2a.cOnly in samsung/drivers/input/misc: gpio_axis.cOnly in samsung/drivers/input/misc: gpio_event.cOnly in samsung/drivers/input/misc: gpio_input.cOnly in samsung/drivers/input/misc: gpio_matrix.cOnly in samsung/drivers/input/misc: gpio_output.cOnly in samsung/drivers/input/misc: k3g.cOnly in samsung/drivers/input/misc: keychord.cOnly in samsung/drivers/input/touchscreen: mxt224.cOnly in samsung/drivers/input/touchscreen: synaptics_i2c_rmi.cOnly in samsung/drivers/leds: ledtrig-sleep.cOnly in samsung/drivers/media/video: s5k4ecgx.cOnly in samsung/drivers/media/video: s5k4ecgx_regs_1_0.hOnly in samsung/drivers/media/video: s5k4ecgx_regs_1_1.hOnly in samsung/drivers/media/video: s5ka3dfx.cOnly in samsung/drivers/media/video: s5ka3dfx.hOnly in samsung/drivers/media/video: samsungOnly in samsung/drivers/mfd: max8998.cOnly in samsung/drivers/misc: ak8973-reg.hOnly in samsung/drivers/misc: ak8973.cOnly in samsung/drivers/misc: akm8975.cOnly in samsung/drivers/misc: apanic.cOnly in samsung/drivers/misc: fsa9480.cOnly in samsung/drivers/misc: kernel_debugger.cOnly in samsung/drivers/misc: kr3dm.cOnly in samsung/drivers/misc: kr3dm_reg.hOnly in samsung/drivers/misc: pmem.cOnly in samsung/drivers/misc: pn544.cOnly in samsung/drivers/misc: samsung_modemctlOnly in samsung/drivers/misc: sec_jack.cOnly in samsung/drivers/misc: uid_stat.cOnly in samsung/drivers/misc: wl127x-rfkill.cOnly in samsung/drivers/net: pppolac.cOnly in samsung/drivers/net: pppopns.cOnly in samsung/drivers/net/wimax: cmc7xxOnly in samsung/drivers/net/wireless: bcm4329Only in samsung/drivers/power: fuel_gauge.cOnly in samsung/drivers/power: s3c_fake_battery.cOnly in samsung/drivers/power: s5pc110_battery.cOnly in samsung/drivers/power: s5pc110_battery.hOnly in samsung/drivers/regulator: max8893.cOnly in samsung/drivers/regulator: max8998.cOnly in samsung/drivers/rtc: alarm-dev.cOnly in samsung/drivers/rtc: alarm.cOnly in samsung/drivers/rtc: rtc-max8998.cOnly in samsung/drivers/rtc: rtc-s3c.hOnly in samsung/drivers/staging: androidOnly in samsung/drivers: switchOnly in samsung/drivers/usb/gadget: android.cOnly in samsung/drivers/usb/gadget: f_accessory.cOnly in samsung/drivers/usb/gadget: f_adb.cOnly in samsung/drivers/usb/gadget: f_mtp.cOnly in samsung/drivers/usb/gadget: s3c_udc.hOnly in samsung/drivers/usb/gadget: s3c_udc_otg.cOnly in samsung/drivers/usb/gadget: s3c_udc_otg_xfer_dma.cOnly in samsung/drivers/video: samsungOnly in samsung/firmware: samsung_mfc_fw.bin.ihexOnly in samsung/fs: yaffs2Only in samsung/include/linux: akm8975.hOnly in samsung/include/linux: android_aid.hOnly in samsung/include/linux: android_alarm.hOnly in samsung/include/linux: android_pmem.hOnly in samsung/include/linux: ashmem.hOnly in samsung/include/linux: cpuacct.hOnly in samsung/include/linux: earlysuspend.h
76
Only in samsung/include/linux: fsa9480.hOnly in samsung/include/linux: gp2a.hOnly in samsung/include/linux: gpio_event.hOnly in samsung/include/linux/i2c: ak8973.hOnly in samsung/include/linux: if_pppolac.hOnly in samsung/include/linux: if_pppopns.hOnly in samsung/include/linux/input: cypress-touchkey.hOnly in samsung/include/linux/input: k3g.hOnly in samsung/include/linux/input: mxt224.hOnly in samsung/include/linux: kernel_debugger.hOnly in samsung/include/linux: keychord.hOnly in samsung/include/linux: keyreset.hOnly in samsung/include/linux: kr3dm.hOnly in samsung/include/linux/mfd: max8998-private.hOnly in samsung/include/linux/mfd: max8998.hOnly in samsung/include/linux/mfd/wm8994: wm8994_pdata.hOnly in samsung/include/linux: nt35580.hOnly in samsung/include/linux: pn544.hOnly in samsung/include/linux/regulator: max8893.hOnly in samsung/include/linux: sec_jack.hOnly in samsung/include/linux: switch.hOnly in samsung/include/linux: synaptics_i2c_rmi.hOnly in samsung/include/linux: tl2796.hOnly in samsung/include/linux: uid_stat.hOnly in samsung/include/linux/usb: android_composite.hOnly in samsung/include/linux/usb: f_accessory.hOnly in samsung/include/linux/usb: f_mtp.hOnly in samsung/include/linux: videodev2_samsung.hOnly in samsung/include/linux: wakelock.hOnly in samsung/include/linux: wifi_tiwlan.hOnly in samsung/include/linux/wimax: samsungOnly in samsung/include/linux: wl127x-rfkill.hOnly in samsung/include/linux: wlan_plat.hOnly in samsung/include/media: s5k4ecgx.hOnly in samsung/include/media: s5ka3dfx_platform.hOnly in samsung/include/net: activity_stats.hOnly in samsung/kernel/power: consoleearlysuspend.cOnly in samsung/kernel/power: earlysuspend.cOnly in samsung/kernel/power: fbearlysuspend.cOnly in samsung/kernel/power: userwakelock.cOnly in samsung/kernel/power: wakelock.cOnly in samsung/mm: ashmem.cOnly in samsung/net: activity_stats.cOnly in samsung/net/ipv4: sysfs_net_ipv4.cOnly in samsung/sound/soc/codecs: wm8994_def.hOnly in samsung/sound/soc/codecs: wm8994_herring.cOnly in samsung/sound/soc/codecs: wm8994_samsung.cOnly in samsung/sound/soc/codecs: wm8994_samsung.hOnly in samsung/sound/soc/s3c24xx: herring-wm8994.cOnly in samsung/sound/soc/s3c24xx: s3c-dma-wrapper.cOnly in samsung/sound/soc/s3c24xx: s3c-idma.cOnly in samsung/sound/soc/s3c24xx: s3c-idma.hOnly in samsung/sound/soc/s3c24xx: s5p-i2s_sec.cOnly in samsung/sound/soc/s3c24xx: s5pc1xx-i2s.cOnly in samsung/sound/soc/s3c24xx: s5pc1xx-i2s.h
77
11.5 Sample process list using ps
$ psUSER PID PPID VSIZE RSS WCHAN PC NAMEroot 1 0 320 184 ffffffff 00000000 S /initroot 2 0 0 0 ffffffff 00000000 S kthreaddroot 3 2 0 0 ffffffff 00000000 S ksoftirqd/0root 4 2 0 0 ffffffff 00000000 S watchdog/0root 5 2 0 0 ffffffff 00000000 S events/0root 6 2 0 0 ffffffff 00000000 S khelperroot 7 2 0 0 ffffffff 00000000 S async/mgrroot 8 2 0 0 ffffffff 00000000 S suspendroot 9 2 0 0 ffffffff 00000000 S sync_supersroot 10 2 0 0 ffffffff 00000000 S bdi-defaultroot 11 2 0 0 ffffffff 00000000 S kblockd/0root 12 2 0 0 ffffffff 00000000 S kseriodroot 13 2 0 0 ffffffff 00000000 S kmmcdroot 14 2 0 0 ffffffff 00000000 S kondemand/0root 15 2 0 0 ffffffff 00000000 S pet_watchdog/0root 16 2 0 0 ffffffff 00000000 S khungtaskdroot 17 2 0 0 ffffffff 00000000 S kswapd0root 18 2 0 0 ffffffff 00000000 S crypto/0root 29 2 0 0 ffffffff 00000000 S kapmdroot 30 2 0 0 ffffffff 00000000 S pvr_timer/0root 31 2 0 0 ffffffff 00000000 S vsync_workqueueroot 32 2 0 0 ffffffff 00000000 S sec_jack_wqroot 33 2 0 0 ffffffff 00000000 S irq/38-sec_headroot 34 2 0 0 ffffffff 00000000 S irq/167-fsa9480root 35 2 0 0 ffffffff 00000000 S mtdblock0root 36 2 0 0 ffffffff 00000000 S mtdblock1root 37 2 0 0 ffffffff 00000000 S mtdblock2root 38 2 0 0 ffffffff 00000000 S mtdblock3root 39 2 0 0 ffffffff 00000000 S mtdblock4root 40 2 0 0 ffffffff 00000000 S mtdblock5root 41 2 0 0 ffffffff 00000000 S mtdblock6root 42 2 0 0 ffffffff 00000000 S spi_gpio.3root 49 2 0 0 ffffffff 00000000 S file-storageroot 50 2 0 0 ffffffff 00000000 S irq/308-mxt224_root 51 2 0 0 ffffffff 00000000 S irq/173-k3groot 52 2 0 0 ffffffff 00000000 S gp2a_wqroot 54 2 0 0 ffffffff 00000000 S kstripedroot 55 2 0 0 ffffffff 00000000 S kconservative/0root 56 2 0 0 ffffffff 00000000 S binderroot 57 2 0 0 ffffffff 00000000 S l2caproot 58 2 0 0 ffffffff 00000000 S krfcommdroot 59 2 0 0 ffffffff 00000000 S irq/334-cypressroot 60 2 0 0 ffffffff 00000000 S max8998-chargerroot 61 2 0 0 ffffffff 00000000 S irq/39-max8998-root 62 1 292 148 ffffffff 00000000 S /sbin/ueventdroot 63 2 0 0 ffffffff 00000000 S yaffs-bg-1root 64 2 0 0 ffffffff 00000000 S mmcqdroot 65 2 0 0 ffffffff 00000000 S yaffs-bg-1root 66 2 0 0 ffffffff 00000000 S jbd2/mmcblk0p1-root 67 2 0 0 ffffffff 00000000 S ext4-dio-unwritroot 68 2 0 0 ffffffff 00000000 S jbd2/mmcblk0p2-root 69 2 0 0 ffffffff 00000000 S ext4-dio-unwritsystem 70 1 816 120 ffffffff 00000000 S /system/bin/servicemanagerroot 71 1 3872 352 ffffffff 00000000 S /system/bin/voldroot 72 1 3856 252 ffffffff 00000000 S /system/bin/netdroot 73 1 676 128 ffffffff 00000000 S /system/bin/debuggerdradio 74 1 9260 1300 ffffffff 00000000 S /system/bin/rildroot 75 1 84796 19680 ffffffff 00000000 S zygotemedia 76 1 25036 2112 ffffffff 00000000 S /system/bin/mediaserverbluetooth 77 1 1264 136 ffffffff 00000000 S /system/bin/dbus-daemonroot 78 1 848 252 ffffffff 00000000 S /system/bin/installdkeystore 80 1 1752 100 ffffffff 00000000 S /system/bin/keystoregps 81 1 14380 3108 ffffffff 00000000 S /system/vendor/bin/gpsdshell 84 1 4464 208 ffffffff 00000000 S /sbin/adbdroot 89 2 0 0 ffffffff 00000000 S pvr_workqueuesystem 110 75 207728 69064 ffffffff 00000000 S system_serversystem 173 75 106008 28668 ffffffff 00000000 S com.android.systemuiroot 183 2 0 0 ffffffff 00000000 S iscan_sysioc
78
root 184 2 0 0 ffffffff 00000000 S dhcp_sysiocroot 185 2 0 0 ffffffff 00000000 S dhd_watchdogroot 186 2 0 0 ffffffff 00000000 S dhd_dpcroot 187 2 0 0 ffffffff 00000000 S dhd_sysiocapp_34 188 75 103132 23732 ffffffff 00000000 S com.google.android.inputmethod.latinradio 192 75 110900 19488 ffffffff 00000000 S com.android.phonenfc 193 75 98940 15308 ffffffff 00000000 S com.android.nfc3app_32 196 75 139612 57312 ffffffff 00000000 S com.android.launcherapp_21 229 75 151300 33340 ffffffff 00000000 S com.google.process.gappswifi 247 1 2176 596 ffffffff 00000000 S /system/bin/wpa_supplicantapp_26 346 75 100420 19000 ffffffff 00000000 S android.process.mediaapp_49 452 75 95880 15956 ffffffff 00000000 S com.android.providers.calendarroot 5258 2 0 0 ffffffff 00000000 S loop0root 5259 2 0 0 ffffffff 00000000 S kdmflushroot 5260 2 0 0 ffffffff 00000000 S kcryptd_ioroot 5261 2 0 0 ffffffff 00000000 S kcryptdapp_82 5404 75 124352 32100 ffffffff 00000000 S com.gowallaapp_28 5416 75 122504 22256 ffffffff 00000000 S com.google.android.apps.mapsapp_1 10655 75 93924 15880 ffffffff 00000000 S com.noshufou.android.suapp_28 10684 75 99540 19328 ffffffff 00000000 S com.google.android.apps.maps:FriendServiceapp_36 10692 75 95896 17544 ffffffff 00000000 S com.google.android.googlequicksearchboxapp_55 10864 75 100768 22024 ffffffff 00000000 S com.doubleTwist.androidPlayerapp_9 10873 75 96988 20340 ffffffff 00000000 S android.process.acoreapp_59 10951 75 93444 16636 ffffffff 00000000 S com.disqus.Disqusapp_25 11080 75 96556 16184 ffffffff 00000000 S com.google.android.apps.uploaderapp_40 11089 75 96216 17948 ffffffff 00000000 S com.google.android.gmapp_74 11097 75 120692 29268 ffffffff 00000000 S com.google.android.apps.plusapp_69 11109 75 97392 19724 ffffffff 00000000 S com.facebook.katanadhcp 11129 1 860 372 ffffffff 00000000 S /system/bin/dhcpcdapp_22 11172 75 106524 21628 ffffffff 00000000 S com.google.android.musicapp_28 11193 75 107976 21668 ffffffff 00000000 S com.google.android.apps.maps:NetworkLocationServiceroot 11215 2 0 0 ffffffff 00000000 S flush-179:0shell 11220 84 744 336 c005bfb4 afd0c3ac S /system/bin/shshell 11221 11220 900 308 00000000 afd0b45c R ps
79
11.6 init.rc Script
on early-init start ueventd
on init
sysclktz 0
loglevel 3
# setup the global environment export PATH /sbin:/vendor/bin:/system/sbin:/system/bin:/system/xbin export LD_LIBRARY_PATH /vendor/lib:/system/lib export ANDROID_BOOTLOGO 1 export ANDROID_ROOT /system export ANDROID_ASSETS /system/app export ANDROID_DATA /data export EXTERNAL_STORAGE /mnt/sdcard export ASEC_MOUNTPOINT /mnt/asec export LOOP_MOUNTPOINT /mnt/obb export BOOTCLASSPATH /system/framework/core.jar:/system/framework/bouncycastle.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar:/system/framework/core-junit.jar
# Backward compatibility symlink /system/etc /etc symlink /sys/kernel/debug /d
# Right now vendor lives on the same filesystem as system,# but someday that may change. symlink /system/vendor /vendor
# create mountpoints mkdir /mnt 0775 root system mkdir /mnt/sdcard 0000 system system
# Create cgroup mount point for cpu accounting mkdir /acct mount cgroup none /acct cpuacct mkdir /acct/uid
# Backwards Compat - XXX: Going away in G* symlink /mnt/sdcard /sdcard
mkdir /system mkdir /data 0771 system system mkdir /cache 0770 system cache mkdir /config 0500 root root
# Directory for putting things only root should see. mkdir /mnt/secure 0700 root root
# Directory for staging bindmounts mkdir /mnt/secure/staging 0700 root root
# Directory-target for where the secure container # imagefile directory will be bind-mounted mkdir /mnt/secure/asec 0700 root root
# Secure container public mount points. mkdir /mnt/asec 0700 root system mount tmpfs tmpfs /mnt/asec mode=0755,gid=1000
# Filesystem image public mount points. mkdir /mnt/obb 0700 root system mount tmpfs tmpfs /mnt/obb mode=0755,gid=1000
write /proc/sys/kernel/panic_on_oops 1 write /proc/sys/kernel/hung_task_timeout_secs 0 write /proc/cpu/alignment 4
80
write /proc/sys/kernel/sched_latency_ns 10000000 write /proc/sys/kernel/sched_wakeup_granularity_ns 2000000 write /proc/sys/kernel/sched_compat_yield 1 write /proc/sys/kernel/sched_child_runs_first 0
# Create cgroup mount points for process groups mkdir /dev/cpuctl mount cgroup none /dev/cpuctl cpu chown system system /dev/cpuctl chown system system /dev/cpuctl/tasks chmod 0777 /dev/cpuctl/tasks write /dev/cpuctl/cpu.shares 1024
mkdir /dev/cpuctl/fg_boost chown system system /dev/cpuctl/fg_boost/tasks chmod 0777 /dev/cpuctl/fg_boost/tasks write /dev/cpuctl/fg_boost/cpu.shares 1024
mkdir /dev/cpuctl/bg_non_interactive chown system system /dev/cpuctl/bg_non_interactive/tasks chmod 0777 /dev/cpuctl/bg_non_interactive/tasks # 5.0 % write /dev/cpuctl/bg_non_interactive/cpu.shares 52
on fs# mount mtd partitions # Mount /system rw first to give the filesystem a chance to save a checkpoint mount yaffs2 mtd@system /system mount yaffs2 mtd@system /system ro remount mount yaffs2 mtd@userdata /data nosuid nodev mount yaffs2 mtd@cache /cache nosuid nodev
on post-fs # once everything is setup, no need to modify / mount rootfs rootfs / ro remount
# We chown/chmod /data again so because mount is run as root + defaults chown system system /data chmod 0771 /data
# Create dump dir and collect dumps. # Do this before we mount cache so eventually we can use cache for # storing dumps on platforms which do not have a dedicated dump partition. mkdir /data/dontpanic chown root log /data/dontpanic chmod 0750 /data/dontpanic
# Collect apanic data, free resources and re-arm trigger copy /proc/apanic_console /data/dontpanic/apanic_console chown root log /data/dontpanic/apanic_console chmod 0640 /data/dontpanic/apanic_console
copy /proc/apanic_threads /data/dontpanic/apanic_threads chown root log /data/dontpanic/apanic_threads chmod 0640 /data/dontpanic/apanic_threads
write /proc/apanic_console 1
# Same reason as /data above chown system cache /cache chmod 0770 /cache
# This may have been created by the recovery system with odd permissions chown system cache /cache/recovery chmod 0770 /cache/recovery
#change permissions on vmallocinfo so we can grab it from bugreports chown root log /proc/vmallocinfo chmod 0440 /proc/vmallocinfo
#change permissions on kmsg & sysrq-trigger so bugreports can grab kthread stacks chown root system /proc/kmsg chmod 0440 /proc/kmsg
81
chown root system /proc/sysrq-trigger chmod 0220 /proc/sysrq-trigger
# create basic filesystem structure mkdir /data/misc 01771 system misc mkdir /data/misc/bluetoothd 0770 bluetooth bluetooth mkdir /data/misc/bluetooth 0770 system system mkdir /data/misc/keystore 0700 keystore keystore mkdir /data/misc/vpn 0770 system system mkdir /data/misc/systemkeys 0700 system system mkdir /data/misc/vpn/profiles 0770 system system # give system access to wpa_supplicant.conf for backup and restore mkdir /data/misc/wifi 0770 wifi wifi chmod 0770 /data/misc/wifi chmod 0660 /data/misc/wifi/wpa_supplicant.conf mkdir /data/local 0771 shell shell mkdir /data/local/tmp 0771 shell shell mkdir /data/data 0771 system system mkdir /data/app-private 0771 system system mkdir /data/app 0771 system system mkdir /data/property 0700 root root
# create dalvik-cache and double-check the perms mkdir /data/dalvik-cache 0771 system system chown system system /data/dalvik-cache chmod 0771 /data/dalvik-cache
# create the lost+found directories, so as to enforce our permissions mkdir /data/lost+found 0770 mkdir /cache/lost+found 0770
# double check the perms, in case lost+found already exists, and set owner chown root root /data/lost+found chmod 0770 /data/lost+found chown root root /cache/lost+found chmod 0770 /cache/lost+found
on boot# basic network init ifup lo hostname localhost domainname localdomain
# set RLIMIT_NICE to allow priorities from 19 to -20 setrlimit 13 40 40
# Define the oom_adj values for the classes of processes that can be# killed by the kernel. These are used in ActivityManagerService. setprop ro.FOREGROUND_APP_ADJ 0 setprop ro.VISIBLE_APP_ADJ 1 setprop ro.PERCEPTIBLE_APP_ADJ 2 setprop ro.HEAVY_WEIGHT_APP_ADJ 3 setprop ro.SECONDARY_SERVER_ADJ 4 setprop ro.BACKUP_APP_ADJ 5 setprop ro.HOME_APP_ADJ 6 setprop ro.HIDDEN_APP_MIN_ADJ 7 setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will# be killed. These numbers are in pages (4k). setprop ro.FOREGROUND_APP_MEM 2048 setprop ro.VISIBLE_APP_MEM 3072 setprop ro.PERCEPTIBLE_APP_MEM 4096 setprop ro.HEAVY_WEIGHT_APP_MEM 4096 setprop ro.SECONDARY_SERVER_MEM 6144 setprop ro.BACKUP_APP_MEM 6144 setprop ro.HOME_APP_MEM 6144 setprop ro.HIDDEN_APP_MEM 7168 setprop ro.EMPTY_APP_MEM 8192
# Write value must be consistent with the above properties.# Note that the driver only supports 6 slots, so we have combined some of# the classes into the same memory level; the associated processes of higher# classes will still be killed first.
82
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,4,7,15
write /proc/sys/vm/overcommit_memory 1 write /proc/sys/vm/min_free_order_shift 4 write /sys/module/lowmemorykiller/parameters/minfree 2048,3072,4096,6144,7168,8192
# Set init its forked children's oom_adj. write /proc/1/oom_adj -16
# Tweak background writeout write /proc/sys/vm/dirty_expire_centisecs 200 write /proc/sys/vm/dirty_background_ratio 5
# Permissions for System Server and daemons. chown radio system /sys/android_power/state chown radio system /sys/android_power/request_state chown radio system /sys/android_power/acquire_full_wake_lock chown radio system /sys/android_power/acquire_partial_wake_lock chown radio system /sys/android_power/release_wake_lock chown radio system /sys/power/state chown radio system /sys/power/wake_lock chown radio system /sys/power/wake_unlock chmod 0660 /sys/power/state chmod 0660 /sys/power/wake_lock chmod 0660 /sys/power/wake_unlock chown system system /sys/class/timed_output/vibrator/enable chown system system /sys/class/leds/keyboard-backlight/brightness chown system system /sys/class/leds/lcd-backlight/brightness chown system system /sys/class/leds/button-backlight/brightness chown system system /sys/class/leds/jogball-backlight/brightness chown system system /sys/class/leds/red/brightness chown system system /sys/class/leds/green/brightness chown system system /sys/class/leds/blue/brightness chown system system /sys/class/leds/red/device/grpfreq chown system system /sys/class/leds/red/device/grppwm chown system system /sys/class/leds/red/device/blink chown system system /sys/class/leds/red/brightness chown system system /sys/class/leds/green/brightness chown system system /sys/class/leds/blue/brightness chown system system /sys/class/leds/red/device/grpfreq chown system system /sys/class/leds/red/device/grppwm chown system system /sys/class/leds/red/device/blink chown system system /sys/class/timed_output/vibrator/enable chown system system /sys/module/sco/parameters/disable_esco chown system system /sys/kernel/ipv4/tcp_wmem_min chown system system /sys/kernel/ipv4/tcp_wmem_def chown system system /sys/kernel/ipv4/tcp_wmem_max chown system system /sys/kernel/ipv4/tcp_rmem_min chown system system /sys/kernel/ipv4/tcp_rmem_def chown system system /sys/kernel/ipv4/tcp_rmem_max chown root radio /proc/cmdline
# Define TCP buffer sizes for various networks# ReadMin, ReadInitial, ReadMax, WriteMin, WriteInitial, WriteMax, setprop net.tcp.buffersize.default 4096,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.wifi 4095,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.umts 4094,87380,110208,4096,16384,110208 setprop net.tcp.buffersize.edge 4093,26280,35040,4096,16384,35040 setprop net.tcp.buffersize.gprs 4092,8760,11680,4096,8760,11680
class_start default
## Daemon processes to be run by init.##service ueventd /sbin/ueventd critical
service console /system/bin/sh console disabled user shell group log
83
on property:ro.secure=0! start console
# adbd is controlled by the persist.service.adb.enable system propertyservice adbd /sbin/adbd disabled
# adbd on at boot in emulatoron property:ro.kernel.qemu=1 start adbd
on property:persist.service.adb.enable=1 start adbd
on property:persist.service.adb.enable=0 stop adbd
service servicemanager /system/bin/servicemanager user system critical onrestart restart zygote onrestart restart media
service vold /system/bin/vold socket vold stream 0660 root mount ioprio be 2
service netd /system/bin/netd socket netd stream 0660 root system
service debuggerd /system/bin/debuggerd
service ril-daemon /system/bin/rild socket rild stream 660 root radio socket rild-debug stream 660 radio system user root group radio cache inet misc audio sdcard_rw
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server socket zygote stream 666 onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd
service media /system/bin/mediaserver user media group system audio camera graphics inet net_bt net_bt_admin net_raw ioprio rt 4
service bootanim /system/bin/bootanimation user graphics group graphics disabled oneshot
service dbus /system/bin/dbus-daemon --system --nofork socket dbus stream 660 bluetooth bluetooth user bluetooth group bluetooth net_bt_admin
service bluetoothd /system/bin/bluetoothd -n socket bluetooth stream 660 bluetooth bluetooth socket dbus_bluetooth stream 660 bluetooth bluetooth # init.rc does not yet support applying capabilities, so run as root and # let bluetoothd drop uid to bluetooth with the right linux capabilities group bluetooth net_bt_admin misc disabled
service hfag /system/bin/sdptool add --channel=10 HFAG user bluetooth group bluetooth net_bt_admin disabled
84
oneshot
service hsag /system/bin/sdptool add --channel=11 HSAG user bluetooth group bluetooth net_bt_admin disabled oneshot
service opush /system/bin/sdptool add --channel=12 OPUSH user bluetooth group bluetooth net_bt_admin disabled oneshot
service pbap /system/bin/sdptool add --channel=19 PBAP user bluetooth group bluetooth net_bt_admin disabled oneshot
service installd /system/bin/installd socket installd stream 600 system system
service flash_recovery /system/etc/install-recovery.sh oneshot
service racoon /system/bin/racoon socket racoon stream 600 system system # racoon will setuid to vpn after getting necessary resources. group net_admin disabled oneshot
service mtpd /system/bin/mtpd socket mtpd stream 600 system system user vpn group vpn net_admin net_raw disabled oneshot
service keystore /system/bin/keystore /data/misc/keystore user keystore group keystore socket keystore stream 666
service dumpstate /system/bin/dumpstate -s socket dumpstate stream 0660 shell log disabled oneshot
85
11.7 Sample MANIFEST.MF
Manifest-Version: 1.0Created-By: 1.0 (Android)
Name: res/layout/main.xmlSHA1-Digest: J291fl4ABGvK1CsYgJEpeDSWEo8=
Name: res/drawable-ldpi/icon.pngSHA1-Digest: i7vxaosoiS+9HzKB7ZgIsXMYRLY=
Name: AndroidManifest.xmlSHA1-Digest: ePodAtUbXFQfUlRNPTvbdnQrXDw=
Name: res/drawable-mdpi/icon.pngSHA1-Digest: 7Ft/Rirt+l/JRX2KjDREScdbCZk=
Name: resources.arscSHA1-Digest: HrkO4tPxiaPdoeNDcDx9bkZfw0s=
Name: classes.dexSHA1-Digest: DMvzC9dwuhlQ6AM7/A/j7d8Ls4Y=
Name: res/drawable-hdpi/icon.pngSHA1-Digest: Vj/qhxk8ic8FE0/kT6E3vgRJ4mE=
86
11.8 Sample CERT.SF
Signature-Version: 1.0Created-By: 1.0 (Android)SHA1-Digest-Manifest: Z4dOkdGC2xQJTdF+PLiUTw8d8qU=
Name: res/layout/main.xmlSHA1-Digest: CCybDEnTwOIdsk2rYh/ebMQ2dZ4=
Name: AndroidManifest.xmlSHA1-Digest: hGh9ygILugOxn+ObWZxRZdhZ29g=
Name: res/drawable-ldpi/icon.pngSHA1-Digest: Z/yxmMxGRNbFUkjqWONvJQH5rQw=
Name: res/drawable-mdpi/icon.pngSHA1-Digest: iR1AGdcgDutAX/5xyl92TWcEJuw=
Name: resources.arscSHA1-Digest: Uh5cbP8vR2hxtdEJm+kXH5gdv0M=
Name: classes.dexSHA1-Digest: cTs5Sx+iEZM8UOoh66Jew7J7kbI=
Name: res/drawable-hdpi/icon.pngSHA1-Digest: 3vv9derC/UrLpiam9i2Yo16eHXw=
87
11.9 Android Application to Test Permissions and Runtime.Exec
package org.thirdly.test;
import android.app.Activity;import android.os.Bundle;import android.os.Environment;import java.io.*;
public class TesterActivity extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); File newFile = getDir("whee", MODE_PRIVATE);!! System.out.println("Can write to " + newFile.getAbsolutePath() + "? " + newFile.canWrite()); try { !File text = new File(newFile, "whee"); !text.setExecutable(true); !FileWriter writer = new FileWriter(text); !writer.append("echo hello world"); !writer.flush(); !writer.close(); } catch (IOException e) { !e.printStackTrace(); } Runtime rt = Runtime.getRuntime(); try {!!!Process proc = rt.exec("ls -l " + newFile.getAbsolutePath() + "/whee");!!!InputStream stdin = proc.getInputStream(); InputStreamReader isr = new InputStreamReader(stdin); BufferedReader br = new BufferedReader(isr); String line = null; System.out.println("<OUTPUT>"); while ( (line = br.readLine()) != null) System.out.println(line); System.out.println("</OUTPUT>");!!} catch (IOException e) {!!!// TODO Auto-generated catch block!!!e.printStackTrace();!!} }}
88
11.10 Sample netstat -a output
# netstat -aProto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 127.0.0.1:7777 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:7203 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:7777 127.0.0.1:56000 ESTABLISHED tcp 0 0 127.0.0.1:7777 127.0.0.1:55999 ESTABLISHED tcp 0 0 127.0.0.1:56000 127.0.0.1:7777 ESTABLISHED tcp 0 0 127.0.0.1:55999 127.0.0.1:7777 ESTABLISHEDtcp6 0 1 ::ffff:10.0.1.16:37799 ::ffff:74.125.71.147:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:44067 ::ffff:74.125.71.104:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:60937 ::ffff:74.125.71.101:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:34032 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:50296 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:38326 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 0 ::ffff:10.0.1.16:51468 ::ffff:107.20.160.88:443 ESTABLISHEDtcp6 0 0 ::ffff:10.0.1.16:57346 ::ffff:74.125.71.188:5228 ESTABLISHEDtcp6 0 1 ::ffff:10.0.1.16:38043 ::ffff:74.125.71.101:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:44053 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:41730 ::ffff:74.125.71.100:443 CLOSE_WAITtcp6 0 1 ::ffff:10.0.1.16:50187 ::ffff:74.125.71.100:443 CLOSE_WAIT
89