Lately, the Android OS has been experiencing phenomenal success. The most recent reports from IDC show that 81% of all smartphone devices sold in Q3 2013 are running Android. If you’re familiar with the industry, this may not surprise you. But what might surprise many people is that Android is being actively used in devices beyond smart phones – and the adoption rate is exploding in these areas as well. The operating system has already been deployed in business IP phones, medical devices, set top boxes, gaming consoles, car dashboards/rear-end systems and a variety of additional vertical markets with new ones coming up every month. Those who have been tracking our coverage of the benefits of using Android beyond phones (see our articles on IoT and Android vs Linux) already know that for any system currently based on Linux that has a need for a rich UX and networking options, Android makes a lot of sense.
As a company that specializes in embedded Android customization, we often work with OEMs who are looking at adopting Android but are concerned about security; they question whether Android is ‘safe enough’ for their product. Some would argue that if Android is so widely deployed in phones, it must be secure, so this concern is unfounded. Unfortunately, that philosophy is not correct. Why? Most smartphones deal mainly with personal data. You have your address book, your pictures, your social networking data and possibly even your passwords in some crypto vault. This is important data, no doubt, and pilferage would range from a mere impediment to complete disaster for you depending on the circumstances. But now take the case for an Android IP Business phone. Such a phone will be wired into your enterprise LAN, which means that if your device is compromised, the theft (and liability as a result of it) could go far beyond you as a single person. Corporate servers could be subsequently compromised, critical data stolen. This would result in significant financial loss to the company.
Let’s look at another example: Android based Class I or Class II medical devices. These are typically FDA regulated, and for good reason. Errors and/or compromises could lead to life threatening situations for the patient. So naturally the concerns for security are more stringent here, especially if they are ‘connected devices’ compared to a standalone, personal phone.
Let’s go back to the basic question at hand: is Android secure enough for different verticals? The simple answer is that it depends on the use-case. The longer answer is that the stock AOSP Android image is not security optimized, but with modifications to the kernel, device management integration and possibly even migrating to SE-Android/Linux, the system can be made very secure.
Of course, in security, there is never a 100% assurance. Security is a multi-layered concept, with each layer adding more security – but it can never be fully complete.
The good news is Android can be customized to be more secure than many existing Linux based phones in the market today. Not because a pure Linux based phone can’t be hardened, it can. It’s just that Android has received so much market focus that incredible effort has been put in to combat security holes or potential areas of exploitation. But there’s still more that can be done.
When it comes to working out how to harden Android, there are two major things to consider.
AOSP (Android Open Source Project) is the stock Android source code that an OEM looking to build their own device first downloads. AOSP contains both the Android Middleware and the Androidized Linux kernel provided by Google. Typically, the OEM starts with this image and adds specific drivers required for support in their target platform (the latter is usually provided by the OEM’s hardware partner). It is surprising to see how many OEMs choose not to make AOSP more secure when they easily could do so. Most OEMs primarily focus on a locked down home screen (i.e. if they are making a specialized system that does not need a generic Android home screen) and quicker boot time, but pay less attention to patching security holes.
So how do you harden AOSP? There are several things you can do (not all of these may be applicable to your device):
There are plenty of other areas that can be optimized and made more secure; these are just a few pointers. Hopefully, they’ve given you plenty to think about.
With respect to security, another interesting development is migrating your system to SE-Android instead of starting with standard Android.
First up, let’s briefly touch on how security works in Android. At a very abstract level, Android’s security policy is UID and GUID based. Remember how in Linux where every user is mapped to a unique uid (with uid==0 is root) and group ids are used to provide access to more than one user? Well, Android is pretty much based on these same rules – except instead of mapping every ‘user’ to a unique uid, it maps every single process to a unique uid. Yes, that’s right. Every process that is installed in Android has a different uid. Furthermore, Android’s default policy is to deny access to applications unless the user (the person using the device) says otherwise.
So theoretically, you would think that this is a great model. And it is actually quite good. But the problem is that users often make mistakes. When they install new applications, they are often asked for permission and without thinking they may allow the application access to too many privileges. Once they do, the application can install malware, download harmful data and more. Therefore, there is a need for a better security policy framework that allows for the inspection of resource usage and patterns that go beyond user permissions.
Enter SE-Android. SE-Android consists of two parts:
SELinux has been around for a while. It’s a hardened form of the standard Linux distribution. The key thing it adds is something called the MAC (Mandatory Access Control) layer, which goes beyond the user-enforced security model discussed earlier (also referred to as DAC or Discretionary Access Control) and offers a centralized security policy that can be customized and allows security policies to be enforced on a per process, per object as well as per operation basis. Simply put, what this means is that even privileged apps (with uid==0) can be restricted from certain operations. One key concept of this is that you can associate security tags with different resources, and write a centralized policy that dictates which processes have access to which resources, irrespective of the uid of the processes.
SEAndroid is a more recent introduction, brought to you by the fine folks at (none other than) SEAndroid. While SELinux has been around for a while, its security policy framework needs to be exposed to the Android level as well. Remember that Android applications run inside their own Dalvik Virtual Machine (DVM) instances. It ties into SE-Linux and also brings with it a MAC policy layer at Android called the MMAC (Middleware Mandatory Access Control) that provides granular security policy enforcements at the Android level. (Technically, SEAndroid could also just be SELinux in enforcing mode, but we think the MMAC is an important part of the framework and hence have included it as part of our definition of SEAndroid)
Linux users may be aware that migrating from standard Linux to SELinux is not very hard. In fact, many distributions like Ubuntu and Debian have rather straightforward mechanisms to migrate to SELinux. Unfortunately, it’s a much harder problem to migrate Android to SEAndroid unless it already includes SELinux. Smalley et. al published a paperon the efforts involved in this, and they are not straightforward. But fortunately for us, since Android 4.3, SELinux has actually been included as part of the Android distribution – just not in enforcing mode. Essentially, this means that while SELinux was a part of the image, its security policies were not really being used for anything except logging access.
Starting with release 4.4 (Kitkat) of Android, SELinux was actually put into enforcing mode and it is now possible to configure the MAC for security policies. In other words, starting with version 4.4 you can actually use the SELinux MAC layer to configure granular policies. Note however that in 4.4, MAC policies have been applied only to a select set of Linux process. Even so, the fact that MAC was enabled and in operation means that this layer can be extended – great news for OEMs building devices! For example, this paper gives a good example of how this helps – it describes an exploit, where a buffer overflow would exploit a well-known uid=0 process (void) and launch a root shell. Using SELinux MAC, one could easily write a policy which would deny command line shell access to void making this exploit fail. The same paper cites many other interesting examples where the SELinux MAC would help thwart other exploits based on uid, and further justify the need for SELinux.
SELinux only works at the Linux process level. The entire Android middleware is then open to exploit. This includes third party Android applications that may be performing unauthorized operations at the Android level (above DVM). Many of these operations may not be visible to the Linux layer and/or may look just like regular IPC calls (becauSEAndroid uses binders for a lot of inter process communications).
Finally, as discussed earlier, the Android security policy is user-based and once the user grants permissions there is no clean way to enforce operation-based security. Given that Android and Linux are really separate layers, it’s not clean to mix Android and Linux permissions together. Therefore, it is necessary to somewhat mimic the Linux MAC at the Android level. And this is exactly what the MMAC does.
Unfortunately, as of today the MMAC layer is very limited (almost absent) in Android mainline. While the folks behind SELinux have made good contributions to the MMAC, it has yet to show up in mainstream Android. Until it does, it is left to OEMs to do this on their own.
When building your next great device using Android, the impact of security issues needs to be assessed based on your vertical. Securing Android is a multi-pronged approach, so you should not only look at hardening your existing kernel/middleware but also look at the viability of basing your product on SEAndroid. While the SEAndroid effort from an MMAC perspective is still not fully integrated into the mainstream Android code, it would benefit new device makers to adopt the SELinux enabled 4.4 and above code branches of Android and build from there. Irrespective of whether you choose to go with SEAndroid or not, for now, you should definitely look at hardening your Android code. The tips provided above should give you enough food for thought to get started.
(Do you find this article interesting? You may want to check out our Embedded Android pages to read more about what we do in this space.)
Do you have an upcoming project and wantus
to help speed up your time to market?
These cookies are necessary for the website to function and cannot be switched off.
These cookies allow us to monitor traffic to our website so we can improve the performance and content of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited or how you navigated around our website.
These cookies enable the website to provide enhanced functionality and content. They may be set by the website or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.