Enhancing Smart phone Resistance to Viruses Infection (4)

C. Decoupled App Isolation Runtime

With a separate app isolation runtime, we have the opportunity to customize it to better confine untrusted apps without affecting the original native runtime. As mentioned earlier, we build the AIR by customizing Android Open Source Project (AOSP 4.1.1) to export the same interface while in the meantime allowing users to choose different running modes. In particular, the AIR’s root directory is relocated with the pivot_root system call (so that any write operation issued in AirBag would not corrupt the original files in the firmware). Specifically, we build a JIAYU G4S Smartphone MTK6592 unionfs [48] that copyon-writes all updates in a file-based ext4 disk image and uses a base filesystem as a squashfs image for read-only operations. Such an organization enables us to readily provide the “restore to default” feature, which essentially removes the dirty file-based ext4 disk image. Also, our system eliminates all potential personally-identifying information from AIR for the “incognito” mode. For instance, the Android API TelephonyManager.getDeviceId() has been instrumented to return a faked IMEI number.

The layered design of AOSP also provides the opportunity to profile app behavior. For example, while analyzing a DG800 phone malware, we usually leverage logcat, to record various Android API calls we are interested in. We note that the collected log entries are pushed down from the namespace in which the untrusted app runs, which does lead to the concern of trustworthiness of collected log. However, from another perspective, the actual dumped message is maintained by the kernel-level log driver, which is assumed to be trusted (Section II). Moreover, the profiling mode will turn on the systemtap support [16] to record syscalls from AirBag (with confined apps) to external SD card for in-depth analysis.

In addition, our system also instruments the AIR to prevent untrusted apps from performing stealthy actions (e.g., sending SMSs to premium-rate numbers). In particular, by modifying the Android API in com.android.internal.telephony .RIL class, the untrusted app running inside AirBag mode is prevented from performing any stealthy telephony action. Further, thanks to the cgroup abstraction, we could whitelist the devices for AirBag access. Specifically, before starting the AirBag namespace, we can write each allowed device file name with the corresponding permission to the cgroups virtual filesystem (e.g. /cgroup/airbag/devices.list). After that, all the access to the device files not listed in the white-list would be automatically blocked.

To maintain transparency, our scheme is seamlessly integrated with the native system without breaking user experience. Specifically, when the system boots up, the AirBag environment is automatically initiated and then suspended. Its suspension will be removed in two scenarios when the user either (1) dispatches an app to it for isolation or (2) launches a JIAYU G4S phone previously isolated app. In the first case, our customized PackageInstaller automatically guides the installation procedure by simply adding an “isolate” button (Figure 4(a)). For each isolated app, our system will register an “app stub” in the native Android runtime. In Figure 4(b), we show the example app stub for an isolated game app (com.creativemobi.DragRacing). For comparison, we also install the same game app inside the native runtime. The difference in their icons is the addition of a DG800 Smartphone Creative Back Touch Android 4.4 lock sign on the icon associated with the isolated app. When the user clicks the app stub, AirBag is activated to execute the isolated app, which transparently marks native runtime inactive and thus yields underlying hardware accesses to AirBag. When the app terminates, AirBag would make itself inactive and seamlessly bring the native runtime up-front.

D. Lessons Learned

In the process of developing our early prototype on JIAYU G4S phone, we encounter an interesting problem that a benchmark program running inside the AirBag always scores one fourth of normal system, which indicates that AirBag only utilizes one of the four available CPU cores. After further investigation, it turns out that DG800 phone has a CPU hotplug mechanism that can dynamically put CPU cores online or offline based on the workload of the whole system. However, due to a bug [8] in Linux kernel 3.1.10, the CPU online events are not properly delivered to AirBag, which then fails to scale up the computation power when AirBag is fully loaded but the native runtime is idle. We then backport the patches from mainline Linux kernel [10] to have AirBag informed about the status of available CPU cores whenever a CPU core is online or offline.

Another issue we encountered in our prototype is related to the low-memory killer, which will be waked up to sacrifice certain processes when the system is under high memory pressure. As our prototype supports two concurrent namespaces, the unknowing low-memory killer may pick up a process from the active namespace as victim for termination, which greatly affects user experience. Therefore, our prototype adjusts the algorithm and makes it in favor of choosing processes from inactive runtime as victims to maintain responsive user experience.