Android (operating system) - Security Model and Integrity

Rooting and Device Security Understanding Android's Storage Architecture Android devices organize their flash storage into separate partitions, each serving a specific purpose. The main partitions include: /system/: Contains the Android operating system and pre-installed system apps /data/: Stores user data, installed applications, and user preferences /boot/: Contains the kernel and ramdisk needed to start the system This partitioning is crucial because it allows the system to protect core OS files separately from user data, which is a foundational security principle. Root Access and Device Control Root access is the highest level of privilege on an Android device. It grants complete control over the entire system, including the ability to modify system files, install any software without restrictions, and bypass security mechanisms. There are two primary ways to obtain root access: 1. Exploiting Security Flaws Attackers or security researchers can potentially gain root access by discovering and exploiting vulnerabilities in the Android OS or device firmware. 2. Unlocking the Bootloader Many device manufacturers allow users to unlock their bootloader through the OEM unlock option in Developer Settings. This is a legitimate but serious action—unlocking the bootloader typically erases all user data and removes security protections. Devices like the Google Pixel, OnePlus, and Nothing phones support this feature via the Fastboot tool. The key insight here is that obtaining root access is a trade-off: gaining complete control requires sacrificing security protections that normally keep the system protected. Core Android Security Features The Application Sandbox One of Android's most important security innovations is the application sandbox. This is an isolated environment where each application runs independently and has no direct access to other apps' data or system resources. Think of it this way: even if you install 10 different apps, they cannot see each other's files or interfere with each other. Each app only has access to: Its own dedicated storage space System resources it explicitly requests Data it creates itself This isolation is enforced at the operating system level, making it difficult (though not impossible) for a compromised app to affect other parts of the system. The Permissions System Android uses an explicit permissions model to control what apps can access. Rather than assuming all apps are trustworthy, Android requires apps to declare what they need to do (like accessing your camera or location) and gives users control over whether to grant those permissions. Evolution: From Installation-Time to Runtime Permissions Before Android 6.0 (Marshmallow): Users had to grant all permissions at installation time. If an app requested permissions you didn't like, you had to choose between installing it anyway or not installing it at all. Android 6.0 and Later: The model shifted to runtime permissions. Now users are prompted to grant or deny individual permissions the first time an app actually needs them. You can also revoke permissions later without uninstalling the app. This change significantly improved user control. However, one limitation remains: pre-installed system apps often have permissions that cannot be revoked and cannot be fully disabled by users. Google Play Protect and Malware Scanning Google introduced several automated systems to protect users from malicious apps: Google Play Protect (formerly Bouncer) has scanned apps in the Play Store for malware since February 2012. This is an automated analysis system that looks for suspicious code patterns and behaviors before apps are made available. Verify Apps (introduced in Android 4.2) goes further by scanning apps that are already installed on your device for malicious behavior. Originally a background process, it was updated in 2014 for continuous scanning and became visible to users in 2017, so you can see when scanning occurs and view results. These tools work together as multiple layers of defense, but they're not perfect—no automated system can catch all threats. Verified Boot and Integrity Protection The Verified Boot Chain One of Android's most critical security mechanisms is the verified boot chain, which ensures that every piece of software loaded during startup hasn't been modified or tampered with. Here's how it works: When your device powers on, the bootloader loads first The bootloader verifies the kernel's cryptographic signature The kernel verifies the system partition's integrity Each step only proceeds if verification succeeds This creates a chain of trust: a hardware-level guarantee that the core system hasn't been compromised. If any part of this chain fails verification, the device refuses to boot, preventing modified or malicious systems from running. A crucial aspect of this system is rollback protection: verified boot prevents you from installing older versions of Android. This protects you from downgrade attacks—where an attacker tries to roll back your device to an older version with known security vulnerabilities. dm-verity: Continuous Integrity Checking While verified boot checks integrity at startup, dm-verity (device mapper-verity) continuously protects the system while it's running. It provides transparent integrity checking of read-only partitions like /system/. Here's why this matters: if malware somehow got into the system partition, dm-verity would detect when the kernel tries to read a modified block and prevent the operation. This helps prevent persistent rootkits—malware that survives reboots by modifying system files. The word "transparent" is important here: the integrity checking happens automatically without requiring app developers or users to do anything special. Security Updates and Patch Distribution The Update Challenge Google's vision for Android security includes regular security patches. Starting in 2015, Google announced that Nexus devices (now called Pixel) would receive monthly security patches and major OS updates for at least two years. However, the industry has struggled to meet this standard. The reality is: Major manufacturers (Samsung, LG, etc.) often take weeks or months to deliver patches after Google releases them Older devices rarely receive updates—support is often limited to 2-3 years Budget devices may receive few or no patches after purchase Fragmentation means some devices never reach the latest Android version The fundamental problem is economic: manufacturers prioritize creating new devices over maintaining old ones. This leaves many devices vulnerable to known exploits long after patches are available. <extrainfo> The Stagefright vulnerability discovered in 2015 was so serious that it prompted Samsung and LG to adopt monthly security patches in August 2015. This vulnerability affected how Android processes media files and could allow remote code execution. </extrainfo> Key Takeaways Android's security approach combines multiple layers: Isolation (sandboxing) prevents apps from interfering with each other Permissions control gives users authority over what apps can access Verified boot and dm-verity protect the system from tampering Automated scanning detects malicious apps Regular patches fix discovered vulnerabilities However, no system is perfectly secure. Users must understand that: Security depends on timely updates, which aren't always guaranteed Rooting or unlocking the bootloader removes important protections Even well-designed systems rely on responsible practices from manufacturers and users