Is Android O as sweet for the developer as it is for the user: Issue One

Android Oreo is finally out and (lackluster launch event aside) it’s a huge step ahead for Android as a secure mobile platform. As much as the update shows the security updations off as if they were cake to add, they legitimately aren’t. Custom ROM developers, buckle them belts. For now, let’s dig in.

Binderized HALs

The change to Binderized HALs is one the changes Android incorporated which deserves a dedicated segment. I’ll quickly go over what Binderized HALs are, taking reference from Jeff Vander Stoep’s post on the Android Developers blog, titled “Shut the HAL up.”

To know what a Binder is, you’ll have to delve a bit into the history of a particular Googler by the name of Dianne Hackborn. Dianne primarily worked on a project named “OpenBinder” at BeboxOS. The project was thereafter taken under Palm, however, the project currently is managed by Google.

OpenBinder, after entering the realms of Android was renamed to “Binder IPC.” The rename is better-suited to the project, since it explains the core workings of the project with the help of two simple words. The term “IPC,” you see, stands for “Inter Process Communication.”

For the readers not familiar with what Inter Process Communication is, here’s a briefing plucked straight out of Surge Raval’s (team substratum) collection of, well, pluckable clippings:

"Binder is generally a shorthand for IPC binder, which means interprocess communication. This usually involves a client and a service, and communicate through the kernel via the /dev/binder of the kernel. In order for them to communicate, the client and remote service needs a way to interface, which is where the Android Interface Description Language is used. The client and remote service must both implement an AIDL file, which generates a stub and proxy that can be used to communicate with each other.The client usually sends a parcelized stub proxy to /dev/binder and the service unparcelizes the message via its stub interface."

Basically, in layman terms, for a Binder based Interprocess Communication, the kernel implements an interface for both the processes to pass Parcels around, which are unparcelized at the application endpoints. The interface needs to be written in a language called AIDL (Android Interface Description Language). How does the binder factor in for HALs? I’ll let Jeff Vander Stoep’s graphics do the explaining (original post linked above)

The illustration above describes the current state of how Android handles Hardware Abstraction Layers (HALs, yeah. Not Hal Jordan. Sorry). Notice the communication mesh via the arrows and how deeply the HALs are integrated into the process they run for.

HALs on O look like the illustration above. HALs are moved out of userspace processes and allowed to live in their own separate processes lowering the attack surface for malware, and is in line with the principle of least privilege, which is a core policy of securing any kind of platform/software. No process has more access than what is absolutely necessary and thus even if exploited, doesn’t get unfettered access to the system. This is achieved by offloading all the work from SystemServer into the HALs themselves and using Binder IPC for communicating with them.

That said (and published,) stay tuned for Issue Two !

In order to interact with the active community, join the official Telegram Channeland exclusive Telegram Group.

Originally published at thecyberfibre.com on August 26, 2017.