-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathhosted-virt.ltx
153 lines (136 loc) · 6.78 KB
/
hosted-virt.ltx
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
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
\documentclass[style=elcolors, mode=present]{powerdot}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{epsfig}
\usepackage{graphicx}
\usepackage{url}
\pdsetup{
lf=Cyber Defense Overview,
rf=Virtual Hosting / Machines
}
\title{Virtual Hosting \& Virtual Machines}
\author{Coleman Kane\\[email protected]}
\begin{document}
\maketitle
\begin{slide}{Virtual Hosting}
Similar to the network partitioning schemes described previously, there exist a menu of options that
enable a single piece of server hardware to be paritioned so as to provide varying levels of isolation
to the applications and users served by this hardware.
\end{slide}
\begin{slide}{Common Virt. Hosting Schemes}
Virtual hosting methods to be covered:
\begin{description}
\item[Environment:] Apache virtual-hosting, Java VM
\item[OS Level:] chroot, Jails, User-mode-Linux
\item[Hypervisors:] VirtualBox, VMWare, Xen
\item[Emulation:] Bochs, VMWare \& VirtualBox under special configuration
\end{description}
\end{slide}
\begin{slide}{Environment Virtual Hosting}
In {\em Environment Virtual Hosting}, virtualization of the hosted applications are configured within
the space of another application instance (typically a parent instance).
\end{slide}
\begin{slide}{Environment Virtual Hosting (cont.)}
Generally the following ground rules are true:
{\small\begin{itemize}
\item The administrator of the server hardware has full visibility and control inside the virtual environments
\item The virtual applications may share, privileges, storage and RAM, unless specifically configured not to
\item Virtual processes are still visible to each other on the server-side
\item The shared nature of the infrastructure is generally opaque to the end-user, but counter-measures must be
authored into the applications in order to ensure this remains true.
\item Compromising one virtual server can put all other virtual servers at risk
\end{itemize}}
\end{slide}
\begin{slide}{Environment Virtual Hosting (dia.)}
\begin{figure}
\epsfig{file=env-virtual-host.eps,height=2in}
\end{figure}
\end{slide}
\begin{slide}{OS-Level Virtual Hosting}
With OS-Level virtualization, you set up independent deployments of whole application stacks
which cannot share each others' configurations, libraries, modules, etc. Configuration of the
virtual environments hosting these deployments will either be configured at the supervisor OS
level, or via specialized "no return" system calls which request that the OS isolate all future
execution and child processes.
\par
In the case of \textbf{User Mode Linux}, a wholly-contained execution environment is created to
run a different Linux kernel as a subprocess of a parent kernel, as a new application.
\end{slide}
\begin{slide}{OS-Level Virtual Hosting (cont.)}
Provides the following features beyond the \textbf{Environment} virtual hosting
{\small\begin{itemize}
\item Can be rooted at a sub-path in the filesystem, restricted from reads/writes outside
of this zone
\item Requires a dedicated instance of the service for each virtual host
\item Lacks dedicated allocation, still competes for system resources,
but executes with significantly limited visibility to other services
\item Individual applications need not be specially configured, and will be relatively
isolated from one another
\item Networking and IPC may still be possible between isolation environments
\end{itemize}}
\end{slide}
\begin{slide}{OS-Level Virtual Hosting (dia.)}
\begin{figure}
\epsfig{file=os-level-virtualization.eps,height=2in}
\end{figure}
Extra cost is incurred by duplicating applications which were shared under application-level virtual hosting
\end{slide}
\begin{slide}{Hypervisor}
A hypervisor further pushes isolation logic up to the hardware level. Requiring special hardware features, the
hypervisor can natively execute code while maintaining lmost complete resource isolation between the instances.
With a few small exceptions, the virtual hosts will execute as completely dedicated OS deployments, requiring
complete OS + application installation within the virtual guest instances.
\par
Parent OS is called "host", while the children are called "guests".
\end{slide}
\begin{slide}{Hypervisor (cont.)}
{\small\begin{itemize}
\item Execute most code natively, but expose a false hardware representation to the "guest" OS
\item Selectively allocate HW devices to guests
\item Dedicate resources or limit resource with fine granularity
\item Abstracted hardware enables suspend, move, restore, close, snapshot of running guest states
\item Most common virtualization associated with "the cloud"
\end{itemize}}
\end{slide}
\begin{slide}{Hypervisor (dia.)}
\begin{figure}
\epsfig{file=hypervisor.eps,height=2.25in}
\end{figure}
\end{slide}
\begin{slide}{Emulator}
Emulators provide an environment which attempts to implement, in software, an entire architecture. The
goal is to provide a method to execute the code in a manner which most closely replicates the underlying
system in which the software would execute. Minimal assistance is provided by the host operating system,
and typically no kernel-level or other supervisory hooks are required. The entire virtualized HW \& SW
stacks live entirely in user-space.
\end{slide}
\begin{slide}{Emulator (cont.)}
{\small\begin{itemize}
\item All code is executed at the application layer
\item Absolutely zero access to the host operating system
\item Host can execute guest code which is incompatible with host architecture (PPC on x86, etc.)
\item 100\% visibility into hardware-level operations
\item Very slow execution
\end{itemize}}
\end{slide}
\begin{slide}{Emulator (dia.)}
\begin{figure}
\epsfig{file=emulator.eps,height=2.25in}
\end{figure}
\end{slide}
\begin{slide}{Hybrid Implementations}
VirtualBox \& VMWare both offer hybrid implementations of Hypervisors and Emulators. This enables these platforms
to adapt to presence/absence of hardwrae \& software facilities which enable hypervisor-based virtualization.
\end{slide}
\begin{slide}{Further Reading}
{\tiny \begin{itemize}
\item \textbf{Apache "VirtualHost" examples}: \url{http://httpd.apache.org/docs/2.2/vhosts/examples.html}
\item \textbf{Best Practices for UNIX chroot() Operations}: \url{http://www.unixwiz.net/techtips/chroot-practices.html}
\item \textbf{FreeBSD Handbook, Chapter 15. Jails}: \url{http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html}
\item \textbf{User Mode Linux}: \url{http://usermodelinux.org/}
\item \textbf{VirtualBox Documentation}: \url{https://www.virtualbox.org/wiki/Documentation}
\item \textbf{Xen Project}: \url{http://www.xenproject.org/}
\item \textbf{QEMU Project}: \url{http://wiki.qemu.org/Main_Page} (emu. for x86, PowerPC, SPARC 32/64, MIPS, ARM)
\end{itemize}}
\end{slide}
\end{document}