Android Security Table of Contents Google Android Security Model -1 ................................................................................................. 2 Google Android Security Model -2 ................................................................................................. 5 Google Android Security Model -3 ................................................................................................. 7 Google Android Security Model -4 ............................................................................................... 10 Google Android Security Model -5 ............................................................................................... 14 Google Android Security Model -6 ............................................................................................... 18 Google Android Security Platform -1 ............................................................................................ 19 Google Android Security Platform -2 ............................................................................................ 20 Notices .......................................................................................................................................... 22 Page 1 of 22 Google Android Security Model -1 Google Android Security Model -1 Android platform is responsible for securing Linux kernel. • Secures user data — Secure inter-process communications • Protects system resources — Removal of unnecessary and/or vulnerable sections of kernel — Access to storage media — Transmission of network data • Application run-time — App Sandboxing limits access to Linux kernel o Mandatory for all apps (native and third party) — Leverages Linux user-based isolation of resources 17 **017 The Android platform is responsible for securing the Linux kernel. So Google-- it's Google's responsibility to make sure that the Linux kernel is secure, that there's not bugs, that there's not security risks inherent with the kernel. The platform also secures user data by securing the inner process communication. It prevents-- or it's supposed to prevent-- applications from talking to one another, applications from accessing the kernel, or making changes to the kernel. Now, depending-- as we'll see, that doesn't always work. Page 2 of 22 Protects system resources: Removal of unnecessary and/or vulnerable sections of the kernel. Again, if Google identifies a portion of the code that is a security risk, it's their job to fix it. They own the source code. Even though it's open source, they're the primary people responsible for the source code. Access to storage media. The platform says where you can write the application to. Can I write it to this area? Can I write it to the media card? The kernel, the platform, makes that decision. And transmission of network data: Can this app transmit over the network? Can it do this? Can it-- that gets into the permission model. When I download an app on an Android phone, I have to say I can write-- or, "I need these permissions." The app has to say, "I need permission X, Y and Z." And I as the user have to say, "Do I want to give the app those permissions or not?" If I don't give those permissions, the app won't install. So I have a binary decision. Do I install it with these permissions, or do I not install it because I don't like the permissions it has? There's no middle ground. I can't say, "Well, it can access these things, but I really don't want it to access the call logs." I don't have that choice as a user. It's all or none, from my perspective. Application run-time: App Sandboxing limits access to the Linux kernel. It's mandatory for all apps, native and third-party. It's also supposed to limit apps interacting with each other. Page 3 of 22 So I have Angry Birds, and I have my Gmail client. Angry Birds should not be able to look at the data in my Gmail client. They're in two separate memory spaces. And it leverages the Linux user-based isolation of resources in order to do this Sandboxing. It's using-- Linux is a fairly secure platform. It has a lot of nice security features built in. It's leveraging those security features in order to help isolate it. They use different parts of RAM. They're not sharing RAM space. They're using different parts of IO. There's not supposed to be any communication between them. Page 4 of 22 Google Android Security Model -2 Google Android Security Model -2 System Partition • Set to “read-only” • System partition contains: — Android's kernel — Operating system libraries — Default applications — Application runtime — Application framework • Safe Mode Access — Enables the device to boot with only default apps 18 **018 The system partition: This is set to read-only. There should not-- apps should not be able to make changes to the system partition. You don't want apps making changes to the system partition. This is equivalent to, say, the System32 folder in Windows. Except more secure. System32, the default build, most of those files shouldn't be changes unless they really have to. And as Windows has progressed, Microsoft has limited more and more what apps can make changes to the System32 folder. Before it was sort of willy-nilly, anybody could do it. Now apps or-- I say apps-- programs in Microsoft have to have explicit user Page 5 of 22 permission to actually write there. So they're changing the security model on the desktop side to try to prevent unauthorized use on the computer side. Well, the OS developers do the same thing on this side. They want to prevent the system kernel from changing. The first step, the easiest step, let's make it read-only. By default, there's no write permissions to the system kernel, or the system partition. The system partition contains the kernel, the operating system libraries, the default applications-- so the applications that are installed by default by the phone manufacturer or by Google-- the application runtimes, the application frameworks. So how do the applications actually work? What are the libraries for the applications? What's the underlying kernel for the phone? All those items are supposed to be read-only. And there's also supposed to safe mode access. So the safe mode access is to allow the device to boot, even if something goes wrong with the phone. So I install some app, and for whatever reason the phone now won't boot. Most Android phones, there's a way to force it into safe mode. And it's exactly like Windows safe mode. So those of you that have used Windows for a long time, you know that when you boot, if there's been a system error, you're usually given the option to load into safe mode. When you load into safe mode, you only have access to Page 6 of 22 certain functionality. It's the baseline functionality. So with safe mode access, if I have an application that crashed my system for whatever reason-- I boot up the phone, and every time the phone boots, that application crashes the phone-- I can boot into safe mode instead and have the ability to remove that application and then reboot into normal mode, and that should fix the crashing problems. That's why safe mode is there. Google Android Security Model -3 Google Android Security Model -3 Android’s secure default core applications • Google WebKit browser • Google calendar • Gmail • Google Maps • Google SMS messenger • Google e-mail client http://www.googleappscentral.com 19 **019 Android's secure default core applications: Google WebKit browser, Google calendar, Gmail, Google Maps, Google SMS messenger, and Page 7 of 22 Google email client. Now, these are the default apps that Google has defined in the operating system. However, manufacturers, depending on the definition document, are allowed to switch out some of these apps for custom apps that provide the same functionality. So if I'm a manufacturer, I don't necessarily have to install Gmail. I can install my own email client as long as it has the same functionality that Gmail does. I don't have to install Google's calendar. I can install a different calendar, as long as it meets the requirements of the definition document. This is one of the greatest strengths and one of the greatest weaknesses of Android devices. Unlike with Apple iPhones, where Apple makes the determination of exactly which apps come by default, and every single phone comes with the same default apps, Google leaves some of this up to the manufacturer. So I, as a user, if I don't do my research, might not know that the HTC phone I just bought isn't using the secure default core applications. It's not using Gmail, or it's not using Google calendar; it's using something HTC put on the phone instead. And how do I know that the applications that HTC just loaded have the same security or secure code that the applications that Google is looking at? Or, if a bug is found, how long is it going to take HTC to update their applications compared to how long it will take Google to update their Page 8 of 22 applications? So it's great that it's customizable. It's great the manufacturers can make customization choices for the phones they're creating. But there's a risk inherent in that. Without using the default apps, you're now left up to the phone manufacturer to be doing the update process, to doing the patching process, making sure that these programs don't have bugs in them. It's no longer Google's responsibility to make sure that HTC's email client doesn't have a bug in it. It's HTC's requirement to make sure that their email client doesn't have a bug in it. Page 9 of 22 Google Android Security Model -4 Google Android Security Model -4 File System Permissions Each app runs as own user Data cannot be shared or changed by other apps • Author of third-party apps can circumvent this OS rule. Android 3.x and later offers full file system encryption • Only available for devices utilizing device passwords • Does not encrypt removable media by default 20 **020 So, file system permissions.