英语原文共 9 页，剩余内容已隐藏，支付完成后下载完整资料
目 录
Android vs. SEAndroid: An empirical assessment 3
2.1. Notes on the interplay in android 7
3. The android security framework 8
3.1. Security considerations on the android security framework 9
Android vs. SEAndroid: An empirical assessment
ABSTRACT
Android has a layered architecture that allows applications to leverage services provided by the underlying Linux kernel. However, Android does not prevent applications from directly triggering the kernel functionalities through system call invocations. As recently shown in the literature, this feature can be abused by malicious applications and thus lead to undesirable effects. The adoption of SEAndroid in the latest Android distributions may mitigate the problem. Yet, the effectiveness of SEAndroid to counter these threats is still to be ascertained. In this paper we present an empirical evaluation of the effectiveness of SEAndroid in detecting malicious interplays targeted to the underlying Linux kernel. This is done by extensively profiling the behavior of honest and malicious applications both in standard Android and SEAndroid-enabled distributions. Our analysis indicates that SEAndroid does not prevent direct, possibly malicious, interactions between applications and the Linux kernel, thus showing how it can be circumvented by suitably-crafted system calls. Therefore, we propose a runtime monitoring enforcement module (called Kernel Call Controller) which is compatible both with Android and SEAndroid and is able to enforce security policies on kernel call invocations. We experimentally assess both the efficacy and the performance of KCC on actual devices.
1. Introduction
Android consists of a Java stack built on top of a native Linux kernel. Services and functionalities are achieved through the interplay of components residing at different layers of the operating system. The Android Security Framework (ASF)consists of a number of cross-layer security solutions combining basic Linux security mechanisms (e.g. Discretionary Access Control), the app isolation offered by the Java Virtual Machine execution environment and Android-specific mechanisms(e.g. the Android permission system).
The security offered by the ASF has been recently challenged by the discovery of a number of vulnerabilities involving all layers of the Android stack (see, e.g., [1–3]). The analysis of these interplay-related vulnerabilities indicates that
bull; the security mechanisms of the Android stack (both Java native and Android-specific) are not completely integrated with those in the Linux kernel, thereby allowing insecure interplay among layers;
bull; malicious and unprivileged Android applications can directly interact with the underlying Linux kernel, thereby by-passing the controls performed by the ASF.
In [1] and [4] we reported a vulnerability in cross-layer interaction that allowed to mount a fork bomb attack on all Android distributions up the release of a patch for 4.0.3 version, in [5] we have carried out an empirical evaluation aimed at deter mining to which extent such a lack of control in the ASF may allow applications to maliciously trigger the Linux kernel functionality by means of properly-forged invocations.
The introduction of the Security Enhancements for Android project (SEAndroid) [6] in the Android Open Source Project(AOSP) since version 4.4.3 calls for a reconsideration of the results reported in [5]. In fact, according to the official documentation, the SEAndroid project aims at enabling the use of SELinux in Android lsquo;lsquo;in order to limit the damage that can be done by flawed or malicious applications and in order to enforce separation guarantees between applicationsrsquo;rsquo; [7] and it should therefore mitigate the aforementioned problems. It must also be observed that SEAndroid suffers from a number of limitations. For instance, the developmentofalsquo;lsquo;goodpolicyrsquo;rsquo;andthetrustworthinessoftheASFarelsquo;lsquo;crucialtotheeffectivenessofSEAndroidrsquo;rsquo; [7].
To illustrate, let us consider the Zygote vulnerability reported in [1]. Such a vulnerability allows a malicious application to force the Linux kernel to fork an unbounded number of processes thereby making the device totally unresponsive. In this case, the problem is due to the fact that the ASF is not able to discriminate between a legal interplay (carried out by trusted Android services) and an insecure one (executed by applications), thereby permitting the direct invocation of a critical kernel functionality (i.e. the fork operation) by any application. This is basically due to a lack of control on Linux system calls involved in the launch of applications. Although SEAndroid is able to address the Zygote vulnerability (by limiting the usage of
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[141435]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
课题毕业论文、外文翻译、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
