-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathabstract.tex
58 lines (54 loc) · 3.09 KB
/
abstract.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
\subsection*{Abstract}
Building secure systems that allow untrusted programs to run without
triggering inherent vulnerabilities %in the underlying privileged code of an
%operating system (OS) kernel or hypervisor
is very challenging.
%Despite substantial effort by o
%eliminate these flaws,
Through techniques such as system call interposition,
operating system virtualization, and library OSes, security researchers
and system developers have attempted to minimize the risk of such flaws.
However, these technologies can add new code to the system's TCB that often has new
exploitable vulnerabilities.
In addition, the complex functions that these systems use can enable access
to portions of the underlying kernel that could trigger these flaws.
%In addition, the portions of the underlying kernel
%that these systems use can open contact to complex calls that can trigger these
%flaws.
This paper introduces a new metric to determine where kernel flaws are
likely to be located, based on the hypothesis that commonly-used kernel
paths, executed by popular applications on a daily basis, contain fewer
vulnerabilities than less-used paths. With this insight, we devise the
safely-reimplement design, a new technique that limits kernel access to only
commonly used paths, and reimplements complex OS functions within a sandbox.
%secured space
%that builds operating system functionality
%using commonly-used primitives.
Finally, we use this design to prototype and test a secure virtualization system called Lind.
The results show that for the 35 bugs we examined in Linux kernel version 3.14.1,
Lind can reduce the threat of attacks on the OS kernel to less than 3\%.
This result is about an order of magnitude better than existing systems like VirtualBox (40\%),
VMWare Workstation (31\%), Docker (23\%), LXC (34\%), QEMU (14\%), KVM (14\%), and Graphene (23\%).
%\gholami{maybe rephrase to: ... these flaws, still it is long away to make
%existing OS kernels secure.}
%However,
%the limitations of these techniques are two-fold. First,
%these systems a
%As a result, developers can not fully prevent buggy programs from triggering
%flaws, or attackers from leveraging these bugs.
%for their own purposes.
%\cappos{Rework...}
%We introduce a novel security design that leverages
%controlled kernel access to protect privileged code from exploitation by
%untrusted programs.
%\gholami {Maybe to say it's called Lind instead of mentioning it at the end of this paragraph}
%We start by analyzing the effectiveness of existing
%solutions and explore the reasons why existing techniques are not
%effective. \gholami {I think this sentence is good inside the paper than abstract?}
%We first propose a new metric to determine where kernel flaws are
%likely to be located, based on a hypothesis that commonly-used kernel
%paths, executed by popular applications on a daily basis, contain fewer
%vulnerabilities than less-used paths. With this insight, we devise a
%novel design that implements essential OS functionality in a
%secure sandbox, minimizing contact between the kernel and riskier system calls.
% \gholami {is this rephrase of the first sentence?}