Android has quite a number of security features that are built into the operating system that significantly reduce the frequency and impact of security issues. The system is designed so that when you build your apps with default system and file permissions, you can avoid having to make difficult decisions about security.
Some of the core security features that can help you build secure apps include
The Android Application Sandbox that isolates all of your app data and code execution.An application framework that has robust implementations of common security functionality, including cryptography, permissions, as well as secure IPC.
Technologies including ASLR; NX; ProPolice; safe_iop; OpenBSD dlmalloc; OpenBSD calloc; and Linux mmap_min_addr that can be used to mitigate risks that are associated with common errors in memory management.
An encrypted files system that can is used to protect data on lost or stolen devices User-granted permissions that restrict access to system features and user data Application-defined permissions that control application data on a per-app basis.
It’s important for you to be familiar with the Android security best practices. By making these practices your general coding habits, you will reduce the chance of inadvertently introducing many security issues that could adversely affect your users.
Dynamically Loading Code
Loading code from outside of your application APK is strongly discouraged. Doing so will significantly increase the likelihood of application compromise because of code injection or tampering. Also, it adds complexity around version management and application testing. Finally, it can make it impossible for you to verify the behavior of an application, so it may be completely prohibited in some environments.
If your application loads code dynamically, the most important thing to keep in mind about is that dynamically loaded code runs with the same security permissions as the application APK. The user may have made a decision to install your application based on your identity, and if so, they are expecting that you provide any code to be run within the application, including code that’s dynamically loaded.
The major security risk that is associated with dynamically loading code is that the code must come from a verifiable source. If the modules are included directly within your APK, they can’t be modified by other applications. This is true no matter if the code is a native library or in a class being loaded that’s using DexClassLoader. There are many instances of applications attempting to load code from insecure locations,like downloaded from the network over unencrypted protocols, or from world writable locations like external storage. These locations might allow someone on the network to modify the content while it is in transit, or another application on a user’s device might modify the content on the device.
Security in a Virtual Machine
The name of Android’s runtime virtual machine (VM) is Dalvik. It was built just for Android, but many concerns about secure code in other virtual machines also apply just as well to Android. In general, you should not be concerned with security issues relating to the virtual machine. Your application will run in a secure sandbox environment, so other processes on the system can’t access your code or private data.
Some virtual machines, such as the JVM or .net runtime, will act as a security boundary that isolates code from the underlying operating system capabilities. With Android, the Dalvik VM isn’t a security boundary. The application sandbox is implemented at the system level, so Dalvik can interoperate with the native code in the same application,without security constraints.
Given the limited storage that comes with mobile devices, it is common for developers to build modular applications and then use dynamic class loading. When doing this, be sure to consider both the source where you retrieved your application logic and also where you store it locally. Don’t use dynamic class loading from sources that aren’t verified, such as unsecured network sources or external storage, since that code might be modified to include malicious behavior.
Security in Native Code
Developers should use the Android SDK for application development, instead of using native code with the Android NDK. Applications that are built with native code are more complex and less portable, and they are more likely to include common memory corruption errors, such as buffer overflows.
If you are going to use native code and you’re familiar with Linux development security best practices, it is especially useful since Android is built using the Linux kernel. However, an important difference between Android and most Linux environments is the Application Sandbox. With Android, all applications run in the Application Sandbox, including those that are written with native code. At the most basic level, a good way to think about it for developers who are familiar with Linux, is to know that all applications are given a unique UID with very limited permissions.
Android has numerous security features that are built into the operating system. These features significantly reduce both the frequency and the impact of application security. With the above points covered, you can build your apps with default system and file permissions to reduce the chance of inadvertently introducing many security issues that could adversely affect your users. The KEY is to put these practices in place so you can avoid difficult decisions in the future about security.