This paper discusses the basic introduction into Android security. It is focused on the last version of Android platform. In the world of numbers it means Android 5.0 with code-name Lollipop. This paper covers description of SELinux and impact on mobile platform, Android Application Sandbox and the whole new virtual machine ART, which was introduced in Android 4.4. The aim of this paper is to introduce the researchers of security principles on Android into new version of thsi operating systems and it's new technologies related to security.
Android is a software stack for mobile devices that includes an operating system,
middle-ware and key applications. In these days it's the most using operating
system on mobile devices on the world. There are a lot of version which are
widespread on mobile devices of di erent manufactures and almost every
manufacturer changed the Android user interface. However under user interface it's
the same Android operating systems with its core and main functionality. We can
say that the most new devices has pre-installed Android version 4.0 and higher.
In November 2014 was introduced new version of this mobile platform - Android
5.0 Lollipop and it has some new features and changes according to previous
versions. This paper is aimed to these features which has impact to Security.
Android 5 brings new view to the security on mobile devices, for example now the
device is encrypted from its beginning. There is analyzed the topic of
SecurityEnhanced Linux which was not mandatory on Android 4. Another new feature
is a new virtual machine which replaced the old Dalvik VM. This paper contain
basic introduction into this new features and also describe the basic knowledge
about functionality of these features.
software. There are many views on the usefulness of SELinux on Linux based
systems, this section gives a brief view of what SELinux is good at and what
it is not (because its not designed to do it). SELinux is not just for military
or high security systems where Multi-Level Security (MLS) [
If SELinux is enabled, the policy de nes what access to resources and operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access unless allowed by policy). This is why SELinux is called a MAC system. The policy design, implementation and testing against a de ned security policy or requirements is important, otherwise there could be \a false sense of security".
SELinux can con ne an application within its own \domain" and allow it to have the minimum privileges required to do its job. Should the application require access to networks or other applications (or their data), then (as part of the security policy design), this access would need to be granted (so at least it is known what interactions are allowed and what are not - a good security goal).
Should an application \do something" it is not allowed by policy (intentional or otherwise), then SELinux would stop these actions.
Should an application \do something" it is allowed by policy, then SELinux may contain any damage that maybe done intentional or otherwise. For example if an application is allowed to delete all of its data les or database entries and the bug, virus or malicious user gains these priviledges then it would be able to do the same, however the good news is that if the policy \con ned" the application and data, all your other data should still be there. User login sessions can be con ned to their own domains. This allows clients they run to be given only the privileges they need (e.g. admin users, sales sta users, HR sta users etc.). This again will con ne/limit any damage or leakage of data.
Some applications (X-Windows for example) are di cult to con ne as they are generally designed to have total access to all resources. SELinux can generally overcome these issues by providing sandboxing services. SELinux will not stop memory leaks or bu er over-runs (because its not designed to do this), however it may contain the damage that may be done. SELinux will not stop all viruses/malware getting into the system (as there are many ways they could be introduced (including by legitimate users), however it should limit the damage or leaks they cause SELinux will not stop kernel vulnerabilities, however it may limit their effects.
Finally, SELinux cannot stop anything allowed by the security policy, so good design is important. SELinux on Android This section explains how the previously noted challenges to enabling the effective use of SELinux in Android were overcome in the SE Android reference implementation. Overcoming these challenges required changes to the kernel, changes and new additions to the Android user-space software stack, and the creation of a new policy con guration for Android. Starting with Android 4.3, (SELinux) is used to further de ne the boundaries of the Android application sandbox.
SELinux operates on the ethos of default denial. Anything that is not explicitly allowed is denied. SELinux can operate in one of two global modes: permissive mode, in which permission denials are logged but not enforced, and enforcing mode, in which denials are both logged and enforced. SELinux also supports a per-domain permissive mode in which speci c domains (processes) can be made permissive while placing the rest of the system in global enforcing mode. A domain is simply a label identifying a process or set of processes in the security policy, where all processes labeled with the same domain are treated identically by the security policy. Per-domain permissive mode enables incremental application of SELinux to an ever-increasing portion of the system. Per-domain permissive mode also enables policy development for new services while keeping the rest of the system enforcing.
In the Android 5.0 L release, Android moves to full enforcement of SELinux. This builds upon the permissive release of 4.3 and the partial enforcement of 4.4. In short, Android is shifting from enforcement on a limited set of crucial domains (installd, netd, vold and zygote) to everything. This means manufacturers will have to better understand and scale their SELinux implementations to provide compatible devices. In other words these changes has impact to:
Using SELinux in Android rst requires enabling SELinux and its dependencies in the kernel con guration and rebuilding the kernel. SELinux dependencies in the kernel include the Linux Security Module (LSM) framework, the audit subsystem, and le-system support for extended attributes and security labels for each relevant le-system for the device. File-systems that do not support extended attributes or security labeling such as vfat can still be used, but can only be labeled and protected at per-mount granularity rather than perle granularity. More recent Android devices have begun using the Linux ext4 lesystem for eMMC storage on Android devices, since eMMC exposes a traditional block-based interface on which conventional disk-based Linux le-systems can be layered. Ext4 already incorporates all the necessary support for extended attributes and security labeling and is already tested with SELinux as part of conventional Linux distributions.
Enabling user-space support for SELinux in Android required changes to a wide variety of software components, ranging from Android's C library implementation, le-system generation tools, and init program up through the Android framework services. It also required porting the core SELinux user-space components to Android.
Let's clarify some concepts related with SEAndroid: Security-Enhanced Linux is an implementation of mandatory access control using Linux Security Modules (LSM) in the Linux kernel, based on the principle of least privilege. It is not a Linux distribution but instead a set of modi cations that can be applied to UNIX*-like operating systems, such as Linux and BSD.
Discretionary Access Control (DAC) [
Mandatory Access Control (MAC) limits privileges for subjects (processes) and objects ( le, socket, device, etc.).
SELinux does not change any existing security in the Linux environment; instead, SELinux extends the security model to include Mandatory Access Control (e.g., both MAC and DAC are enforced in the SELinux environment). SEAndroid enhances the Android system by adding SELinux support to the kernel and user space to:
Con ne privileged daemons to protect them from misuse and limit the damage that can be done via privileged daemons.
Sandbox and isolate apps from each other and from the system. Details about Android Application Sandbox folows in next section.
Prevent privilege escalation by apps.
Allow application privileges to be controlled at installation and runtime using middleware mandatory access control.
Provide a centralized, analyzable policy.
Furthermore, in Android 4.4, SEAndroid is enabled in the Enforcing mode, instead of the non-functional disabled mode or the noti cation-only permissive mode, which means that any invalid operation will be prohibited in the Android run-time environment. In Android 5.0 has been setup full enforcement, as was described in this section.
Application sandboxing, also called application containerization, is an approach
to software development and mobile application management (MAM) that limits
the environments in which certain code can execute. The goal of sandboxing is to
improve security by isolating an application to prevent outside malware,
intruders, system resources or other applications from interacting with the protected
app. The term sandboxing comes from the idea of a child's sandbox, in which the
sand and toys are kept inside a small container or walled area. Android uses the
concept of a sandbox [
Android is a mobile operating system mainly used for mobile devices, tablets or
TVs. Android is based on Linux kernel as was discussed earlier, supplemented
with middleware and libraries written in C/C++, yet Android application (app)
itself is written in Java and run with the Android framework and Java-compatible
libraries. Android can enjoy the full bene t of Java such as platform
independence, added security, and ease of app development. Android had its own virtual
machine (VM) to execute Java application, called Dalvik VM [
Generally, one of Java's advantages as a mobile software platform is a platform independence, achieved by using the bytecode that can be executed by the interpreter on any platform without porting. Since this software-based execution is much slower than hardware-based execution, just-in-time compilation for translating bytecode into machine code at runtime has been used in the Java VM. The Dalvik VM is not an exception and it also employs JIT compilation. However, there are some di erences in the JIT compilation techniques used in the two VMs. Dalvik VM has been used until Android 4.4 was introduced. In this version of operating system the user can choose between two types of VM - Dalvik VM or ART. In Android 5.0 Lollipop is only one version and it is the new VM called ART or Android RunTime.
Android runtime (ART) is the managed runtime used by applications and
some system services on Android. ART and its predecessor Dalvik were originally
created speci cally for the Android project. ART as the runtime executes the
Dalvik Executable format and Dex bytecode speci cation. ART and Dalvik are
compatible runtimes running Dex bytecode, so apps developed for Dalvik should
work when running with ART. However, some techniques that work on Dalvik do
not work on ART. ART introduces ahead-of-time (AOT) compilation [
Parallelized processing during the remaining GC pause Collector with lower pause time for the special case of cleaning up recentlyallocated, short-lived objects Improved garbage collection ergonomics, making concurrent garbage collections more timely, which makes GC FOR ALLOC events extremely rare in typical use cases
ART currently does not use compacting GC, but this feature is under development in the Android Open Source Project (AOSP). In the meantime, don't perform operations that are incompatible with compacting GC, such as storing pointers to object elds. Information about ART comes from o cial site of Android project.
There are some basic information, that comes from comparison of virtual machines. The new ART VM has better performance on executing application, because the whole application now runs from compiled code. On the opposite the application takes more memory on ash disc. This is related to bytecode (or compress bytecode), where one instruction means more instruction in binary code. In these day when the cost of memory is low we do not have a problem with space on mobile devices. The performance is no the most important pointer in development.
Improvement of the whole security model in Android version 5.0 has impact to keep users safe and try to protect them before hackers, attackers and also from processes or malware applications. This paper explains new security features of new Android operating system and how these features work. Combination of these changes make a big jump to forward in comparing to older versions. The new Android 5.0 Lollipop o ers mandatory access control, encrypted disc, encrypted memory, new virtual machine which improves performance and still keep application separate through Sandbox. There are some questions about backward compatibility, but it is not related to this article.
Acknowledgement. This article was created within the research plan of the Security-Oriented Research in Information (MSM0021630528). This work was supported by the European Regional Development Fund in the IT4Innovations Centre of Excellence project (CZ.1.05/1.1.00/02.0070) and by the project Advanced Secured, Reliable and Adaptive IT (FIT-S-11-1).