Linux security measures
Sandboxing in kernel
Permissions enforced through linux groups
Each app separate UID
Not a security boundary
■ No security manager
■ Permissions are
enforced in OS, not VM
■ Bytecode verification
optimized for speed, not
■ Every app can execute
Zygote process preloads typical classes and
dynamic link libraries
■ Only when new process writes page, new
page is allocated.
■ All pages not be written are shared
among all zygote children.
Exec system call is not used in zygote.
■ wipes the page mapping table of process.
■ It means exec discards zygote cache.
Runs as UID=0 (root). After forking child
process, its UID is changed by setuid
■ IPC via kernel interface
■ Used under water for all IPC in Android
• Service to application
• Service to system
• But also Intent-based communication...
■ Is security-aware and passes calling UID & GID
27 januari 2014
Powerpoint ICT Automatisering
Additional measures in Android 4.2
■ Additional scan for
installd/init handling, etc
Checks every app submitted to store
Runs app for 5 minutes in emulator,
If flagged: manual analysis
Combination of dynamic/static
Submit flagged apps too many times
→ blocked account
Additional measures in Android 4.3
Android sandbox reinforced with SELinux.
No setuid/setgid programs.
Restrict Setuid from Android Apps.
Additional measures in Android 4.3 cont'd
NO_NEW_PRIVS. (This requires Linux kernel version 3.5
Additional measures in Android 4.4
Android sandbox reinforced with SELinux in enforcing
ECDSA Provider support in AndroidKeyStore.
Device Monitoring Warnings
FORTIFY_SOURCE level 2
Used to verify underlying
boot image is not
Mandatory Access Control (MAC) for Linux
Enforces a system-wide security policy
Over all processes, objects, and operations
Based on security labels
Can confine flawed and malicious applications
Even ones that run as “root” / uid 0.
Can prevent privilege escalation
Difference between DAC and MAC
DAC: owner of object (f.i. files) determines access level
MAC: system determines access level
Communication between OS and
applications via Intents
OS resolves requested action
(e.g. 'edit contact') with all
registered Intent receivers
Highly versatile and modular
Allows changing out default
functionality for alternatives
Permissions determine if
an app can perform an
Permissions checked when:
■ Starting activities
■ Starting/binding to services
■ Sending to BroadcastReceivers
■ Accessings ContentProviders (separate for read and
■ … and at any given moment using
All Android applications must be signed by the author (developer)
Signing: process of digitally signing a given application using a private key to:
■ Identify author
■ Detect changes
■ Establish trust between applications
On Android, certificate (X.509) can be self-signed, no need for a certificate
Android applications can be built in debug and release-mode:
In debug mode the app is automatically signed with debug key and cannot be
distributed (e.g. via Google Play)
In release-mode app is signed with private key of developer.
Full-disk encryption using dm-crypt
■ Actually: /data partition
Done using 128 bit AES/SHA256
Master key encrypted with another key based off device
■ Problem: since PIN is usually 4 digits long, cracking
master key is matter of little time...
Locate lost devices
Enable remote wipe
Can disable functionality
(such as camera)
Support for VPN connections based on
■ Own VPN implementation (3rd party, 4.0+)
Requires use of device lock mechanism
As of Android 4.2, always-on VPN is possible too
■ Based on SE Android with additional policies
■ Separate USER and Work partitions
■ Verified boot
■ Per-app VPN
■ More comprehensive mobile device management