What Security Android Provides? An Explanation from Mobile Architect & Cyber Security Expert – Mahabir Gupta

By Ganapathi on

Android is one of the popular mobile-phone operating systems in the world, and also used for other touchscreen operating devices. It is owned by Google.  

HOW THE ANDROID SECURITY MODEL FUNCTIONS?

Android Security Mechanism: The objective of this article is to identify how android provides security. To narrow down the strength and weakness in the security model of Android operating system, it is broadly divided into three groups:

  1. Security Features inherited from Linux: It has three ways to implement or provide security which are Users, File Access and Selinux Policy .
  2. Android Specific: It has Application Sandboxing, Secure inter-process communication, Application signing and Application-defined and user-granted permission
  3. Environmental: Environmental has Memory Management Unit and Trusted Execution Environment (TEE)

Security Features Inherited from LINUX:

The Linux kernel is the foundation of android platform. It is a multiuser operating system, with the main security objective to mutually isolated different user.

Users:

Each users in the Linux system assigned a unique user ID(UID) and group ID(GID) when they created. Each user UID’s resource is assigned the same UID, process, file, directory, etc.

On each access by a user or process to a given resource, the linux kernel enforces the access control policy based on the access right and the requestor UID/GUID. The linux kernel acts a reference monitor.

File Access:

File access – In linux, there is 3 types of users

3 types of users (subjects)

u – user who owns a file

g – group user (all the members of the group g)

o – all other users

3 types of permissions (access rights)

r – read file or directory

w – write to file or directory

x – execute file or search directory

Given a file (object), each of the 3 access rights can be set for any of 3 types of users by the file owner (u)

Almost everything in Linux is viewed as a file

POSIX  permission example

Recaps on Android partition

In Android,  the system application and programs are installed in a read only partition/System.

Users installed application and updates are install in the user/data partition.

Android File Access Caveats – Data written to external storage (such as SD cards) lacks Linux access control. Any file written to external storage is accessible by any app on the

device (and by any other external device supporting such storage).Sensitive assets must be securely stored.

#Root user has access to all the files in the file system.

Android Sandboxing: The sandbox security mechanism is achieved in kernel layer. Each app get a unique UID when forked from zygote and run in the separate process. It can access only own file system(unless root). If file or memory get corrupted, it call only affect one sandbox.

On Android, each app is effectively a different user. Some exception are available (If they share user id).

User Id(UID) are assigned when an android package is installed by the package manager.

Note : /data/system/package.xml file contain info about every installed application

All data stored by the app have the same UID(e.g, dir, files ,Db ,etc).

Application Authentication: All android app must be digitally signed prior to installation. The developer signed the corresponding apk by his/her digital certificate(i.e corresponding the private key).

Android uses the digital certificate as a mean of

  • Identify the developer of an application – Used to ensure the authenticity of future application updates(same origin policy).
  • Established the trust relation between application – Application signed with the same certificate can share user id for file system resource and runtime process.

App authentication

    • Each app (apk) is signed by developer and signature verified by install time.
    • System apps are signed by set of platform keys
    • No CAs (and no code-signing certificate from Google)
    • Malicious app untraceable to author (however need to pay market fee to sell)
    • Apps with the same UID must have been signed with the same key
    • Apps can declare “Signature” permissions to other apps.

APK signature scheme signing V1

Application signature scheme V2

    • Introduced in Android 7
    • Increased verification speed and strengthens integrity guarantees
    • V2 scheme treats the APK file as blob and performs signature checking for the entire file

Format signing Block:

Size of block in bytes (excluding this field) (uint64)

  • Sequence of uint64-length-prefixed ID-value pairs: •ID (uint32)
  • value (variable-length: length of the pair – 4 bytes)
  • size of block in bytes—same as the very first field (uint64)
  • magic “APK Sig Block 42” (16 bytes)

Janus Vulnerability (December 2017) CVE-2017-13156

      This signature scheme does protect some parts of APK such as ZIP metadata.

    • Janus vulnerability exploits the possibility to add extra bytes to DEX and APK files
    • The root of the problem is that a file can be a valid APK file and DEX file at the same time.
  • APK Meta Information (META-INF/)

 META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity

    • The signing process is based on cryptographic hash functions (e.g., SHA1) and
      public-key cryptography

APK Meta Information (META-INF/)

META-INF/ files hold necessary information (crypto hashes, certificate and signature) to verify the package integrity

    • The signing process is based on cryptographic hash functions (e.g., SHA1) and
      public-key cryptography

Application Upgrade

    • Applications can register for auto-updates
    • Applications must have been signed with the same (private) key.
    • No additional permissions should be added
    • Install location is preserved

Security of Android Components

Permission

  • Can be 1. Built-in 2. App-defined
  • Used to protect:
      • System sensitive API from app calls
      • Apps from each other (mutually distrusting)
  • Managed by package manager (/data/system/packages.xml)
  • Permission level

Normal

Dangerous

Signature

SignatureOrSystem

Android Manifest

Applications do not have default permissions

Each application can declare the required permissions”.

<?xml version=”1.0″ encoding=”utf-8″?>
<manifest . . . >
    <application . . . >
        <activity android:name=”com.example.project.myActivity“

android:permission=“com.myapp.mypermission”

android:exported=“true”>
          <intent-filter>

               <action android:name=”android.intent.action.MAIN” />

               <category android:name=”android.intent.category.LAUNCHER” />

             </intent-filter>

                        . . .  
        </activity>
        <activity> ….. </activity>

     <uses-permission android:name=”android.permission.SEND_SMS” />

     <uses-permission android:name=”android.permission.INTERNET” />  . . .
    </application>
</manifest>

    • Android’s permission only restricts components from accessing resources
      • E.g. an application needs the READ_CONTACTS permission to read the user’s address book
    • If a public (exported) component doesn’t explicitly declare  any access permission, Android allow any application to access it.
    • Custom permissions are declared in the application manifest with the <permission> tag.
  • Android Permission Model
    • Permissions are the core concepts in the Android security to control the access from one application component to another.
    • Before 6.0 All permissions are set at installation time and can’t change until the application is reinstalled.
    • Starting from Android 6.0 (Marshmallow) application permissions can be individually toggled ON/OFF by the user.

Components are declared in app manifest

SELinux

    • Used from Android 4.3 up
    • Introduces MAC
    • Default denial access control based on minimal privilege

     Modes                    

  •      Permissive (denied permissions are logged but not enforced)
  •      Enforcing (denied permissions are logged and enforced)
  • A 4.3 Permissive mode ➔ A 4.4 Partially enforcing ➔ A 5.0 Full enforcing mode
    • Defines Domains (Set of identically labeled processes) to be treated equally by security policy
    • Have to create & maintain security policies

Mandatory Access Control (MAC)

Processes ➔ Subjects

System resources ➔ Objects

(Bell-La Padula model)

  • MAC is applied if DAC permits
  • Bell-La Padula model
      • Confidentiality safeguard
  • Android app-level MAC
    • In DAC permissions cannot be revoked
    • SELinux policy is checked if DAC allows and action

SELinux in Android 5.0 Lollipop

All system services and apps are confined.

  • Including root daemons.

Only two domains are “unconfined”.

  • kernel and init

Even these two domains are not completely unrestricted by SELinux.

  • TCB protection goals are applied universally.
  • No domain/process is all-powerful

Service-specific Protection via SELinux

Android keystore

  • Provides secure storage of keys.

SELinux kernel-enforced guarantees:

  • Nothing can ptrace the keystore.
  • Nothing else can open /data/misc/keystore files.

SELinux userspace access control:

  • Keystore checks SELinux policy for client requests.
  • Sensitive operations restricted via policy

SELinux in Android 8.0

SELinux in Android 8.0 is now supporting modularity and updatebilitiy of SELinux Policies.

  1. The ​SELinux ​policy ​build ​flow ​for ​Android ​4.4 ​through ​Android ​7.0 ​merged ​all ​sepolicy fragments ​(platform ​and ​non-platform) ​then ​generated ​monolithic ​files ​in ​the ​root directory.

However, ​this ​flow ​contradicts ​the ​primary ​goal ​of ​Android ​8.0 ​architecture, which ​is ​to ​allow ​partners

  1. ​to ​update ​their ​parts ​of ​the ​policy,
  2. ​build ​their ​images (vendor.img, boot.img, etc),
  3. ​then ​update ​those ​images ​independent ​of ​the ​platform ​or vice ​versa ​(i.e., ​perform ​a ​platform ​update ​without ​updating ​partner ​images).

Android ​8.0 ​design ​goals ​are:

  • Policy ​Modularization: ​In ​Android ​4.4 ​through ​Android ​7.0, ​most ​SELinux ​files ​resided in rootfs, ​thus ​SoC ​vendors ​and ​the ​ODM ​partners ​modified boot.img ​(for ​non-A/B devices) ​or system.img ​(for ​A/B ​devices) ​every ​time ​policy ​was ​modified.
    • ​The ​Android 8.0 ​model ​provides ​a ​method ​for ​vendors ​and ​partners ​to ​change ​only​their ​partitions when ​they ​need ​to ​modify ​their ​portions ​of ​the ​SELinux ​policy.
  • Policy ​Compatibility. ​On ​devices ​running ​Android ​8.0, ​it ​is ​possible ​to ​upgrade ​the platform ​image ​ahead ​of ​vendor/partner ​images; ​this ​can ​occur ​during ​an ​over-the-air (OTA) ​update, ​such ​as ​a ​framework ​OTA.
  • system.img. ​Contains ​mainly ​Android ​framework.
  • boot.img. ​(kernel/ramdisk) ​Contains ​Linux ​kernel ​+ ​Android ​patches.
  • vendor.img. ​Contains ​SoC-specific ​code ​and ​configurations.
  • odm.img. ​Contains ​device-specific ​code ​and ​configurations.
  • oem.img. ​Contains ​OEM/carrier-related ​configurations ​and ​customizations.
  • bootloader. ​Brings ​up ​the ​kernel ​(vendor-proprietary).
  • radio. ​Modem ​(proprietary)

Prior ​to ​Android ​8.0, ​the vendor, odm, ​and oem ​images ​were optional; ​files ​belonging ​to these ​images ​were ​placed ​in boot.img ​or system.img ​with ​symlinks ​(such ​as /vendor ​> /system/vendor) ​when ​absent. ​Android ​8.0 ​makes ​the ​vendor ​partition mandatory.

IPC Communication

In order to support communication between different processes, Android provides a simple inter-process communication (IPC) mechanism which allows different process to share information.

Inter-Process Communication

  • Linux way
      • Socket
  • Shared files                                                        
  • Android way   
  • Binder
  • AIDL
  • Intents – can apply permissions w.r.t. sender and define receivers

Files as IPC(Inter-Process Communication)

Processes can use shared–preferences Files as a way to implement IPC, This can be achieved in two ways:

    • Setting the flag MODE_WORLD_READABLE while creating the file
    • Use the android:sharedUserId tag in the application manifest

The use of the file-system as IPC is discouraged.

Security for Inter-Process Communication: 

In addition to any Linux-type process communication mechanisms such as file system, local sockets,  signals Android provides new IPC mechanisms:

Intents as IPC

Intent messaging is a framework for asynchronous communication among Android components. The context object can make use of Intents to communicate with different processes, the method  putExtra can be used to send data to the server process

Intents as IPC II

Only the exported components can be started by external intents, By default, components can only receive internal Intents

(note: broadcastReceivers are exported by default)

Intents can be restricted by using application permissions

    • Services and Activities

Should use <permission> tag to require permissions from the clients

    • BroadcastReceivers

Intents can limit the broadcast receivers capable of receiving the broadcast message by defining a not-null permission in the method call broadcastIntent (Intent, Permission)

Eavesdropping Intents

intent.setComponent and intent.setAction methods, can be used to declare the intent receiver

Binder

  • “Binder has the facility to provide bindings to functions and data from one execution environment to another.”
  • Client-server comm. (client initiated)
  • Binder can write part of each process’ memory. Processes can only read it
  • No RPC supported can be built on top
  • Communication is guaranteed by using Linux PIDs & EUIDs provided by the kernel (i.e. processes cannot fake ID)

Binder communication

Data transmitted (Parcel)

Binders and Services

    • Services can override the onBind method in order to provide binder interfaces to the clients
    • On the client side Binders can be obtained by calling the context.bindService method with an Intent.
    • Binders are then casted to the proper object by using the Interface declared by the AIDL definition.
    • Service Binders can be protected by  Android permissions

AIDL

    • AIDL (Android Interface Definition Language) is an IDL language used to generate code that enables two processes on an Android-powered device to talk using inter-process communication (IPC).
    • The AIDL IPC mechanism is interface-based, similar to COM or CORBA, but lighter weight. It uses a proxy class to pass values between the components
    • When an AIDL file is included into the src folder of the android project the SDK generates an interface that can be used by the android application

Global Services

Global (System) services can be registered and obtained by the following methods:

ServiceManager.addService

ServiceManager.getService

System services are not protected by static permissions but they can implement security by verifying the caller identity and permissions:

      • android.os.Binder.getCallingUid
      • PackageManager.getPackagesForUid(int uid)
      • PackageManager.getPackageInfo (with the PackageManager.GET_PERMISSIONS flag)

Binders and Services

    • Services can override the onBind method in order to provide binder interfaces to the clients
    • On the client side Binders can be obtained by calling the context.bindService method with an Intent.
    • Binders are then casted to the proper object by using the Interface declared by the AIDL definition.
    • Service Binders can be protected by  Android permissions

System Services

System services can be registered and obtained by the following methods:

ServiceManager.addService register

ServiceManager.getService obtain

System services are not protected by static permissions but they can implement security by verifying the caller identity and permissions:

      • android.os.Binder.getCallingUid
      • PackageManager.getPackagesForUid(int uid)
      • PackageManager.getPackageInfo (with the PackageManager.GET_PERMISSIONS flag)

Full Disk Encryption

  • From android 5 Full disk encryption is enabled for the /data partition.
  • Set from the user PIN/Pattern code
  • If not set a default “password” is used.

Consequences of Rooting:

  • Bootloader ➔ if unlocked then flash arbitrary ROM into device. Locked bootloader: either commands are encrypted with SBK (Secure Boot Key) or image is signed
  • Recovery OS ➔ for reformatting of data partition, flash ROM. (update.zip in root of microSD card, signed by vendor). Root user can replace recovery with custom one.
  • ADB (Android Debug Bridge) ➔ can run shell on device. Shell runs as root if ro.secure==0 or as unprivileged user if ro.secure==1. Value of ro.secure comes from
  • default.prop in root directory on boot-time which comes from a partition in internal storage. To write to partition one needs root access.
  • su/sudo ➔ Needed to achieve privilege escalation in Linux (only su can run setuid(0)) to change process privilege. Stock OEM ROMs don’t come with su/sudo!

Conclusion: Linux-inherited and IPC security mechanisms of Android provide a layer of security. Authenticity of apps with signatures of Android applications mitigate the risks of hacking and vulnerabilities. Encryption has to be properly used in combination with TEE/secure element when possible and Rooting always a threat.

Mahabir Gupta currently works at Volvo Corporation in Gothenburg (Göteborg), Sweden. He can be contacted at mahavir9008@gmail.com