steveej/msc-thesis
1
0
Fork 0
Code Issues 1 Pull requests Projects Releases 4 Packages Wiki Activity Actions

thesis: adhere to the one sentence per line rule

Browse source
This commit is contained in:
steveej 2016-11-29 17:30:29 +01:00
parent 9e9fb6b2f3
commit 0abd72b3be
1 changed files with 19 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

24
src/docs/parts/context/context.tex
View file

@ -8,10 +8,15 @@ The technology combines \gls{virt} techniques with new approaches to \gls{app} d
The two main drivers for this technology have been long standing problems in information technology; optimal utilization of hardware and correct deployment of software to said hardware, both without sacrificing security.
The optimal utilization of hardware is done by collocating and running multiple \glspl{app} simultaneously on the same hardware.
In order to increase security, these applications are separated by applying \gls{virt} techniques. By developing \gls{virt} techniques into the \gls{OS} and thereby providing low-level security mechanisms, the foundation of \glspl{sac} was formed. In the next chapter an introduction to \gls{virt} is given, as it is important to understand this aspect of the \gls{sac} technology.
In order to increase security, these applications are separated by applying \gls{virt} techniques.
By developing \gls{virt} techniques into the \gls{OS} and thereby providing low-level security mechanisms, the foundation of \glspl{sac} was formed.
In the next chapter an introduction to \gls{virt} is given, as it is important to understand this aspect of the \gls{sac} technology.
The correctness of software deployment is not easily measurable by quantity like hardware utilization, but is of qualitative nature.
The \gls{sac} approach is to deploy self-contained bundles for \glspl{app} in form of \glspl{saci}. The creation of these \glspl{saci} is the main concern of this thesis and will be the subject to research and development in part \ref{part:research}. The underlying problems related to conventional \gls{app} deployment are covered in chapter \ref{chap:sdd}. State of the art attempts to solve these problems using \glspl{saci} are introduced and critically discussed in chapter \ref{chap:saci}, detailing the problem statement for this thesis.
The \gls{sac} approach is to deploy self-contained bundles for \glspl{app} in form of \glspl{saci}.
The creation of these \glspl{saci} is the main concern of this thesis and will be the subject to research and development in part \ref{part:research}.
The underlying problems related to conventional \gls{app} deployment are covered in chapter \ref{chap:sdd}.
State of the art attempts to solve these problems using \glspl{saci} are introduced and critically discussed in chapter \ref{chap:saci}, detailing the problem statement for this thesis.
\chapter{\Gls{virt}}
\label{chap:virt}
@ -24,7 +29,8 @@ Virtualization techniques can be grouped by two categories: \glspl{hypervisor} a
The term \gls{hypervisor} is synonymous to the more self-explanatory terms control program \cite[p. 217]{Sarton1975} and \gls{VM} Monitor.
The \gls{hypervisor} operates on a host machine and can control multiple \glspl{VM}.
The principle is easy to understand, because one can simply picture one or many virtual computers running on a real computer.
\glspl{VM} are presented with a set of virtual hardware resources. These don't necessarily exist in the presented form on the underlying hardware machine.
\glspl{VM} are presented with a set of virtual hardware resources.
These don't necessarily exist in the presented form on the underlying hardware machine.
\subsection{Guest \glspl{OS}}
In order to be able to boot the virtual hardware and run \glspl{app}, \glspl{VM} need an \gls{OS} to run applications.
@ -38,7 +44,9 @@ This allows to create heterogeneous scenarios like running an ARM \gls{VM} using
\subsection{\Gls{fs} Storage Isolation}
\label{sect:vm-fs-isolation}
The \gls{OS} running inside a \gls{VM} is typically presented with a virtual disk drive. The guest \gls{OS} has to implement the driver for this virtual disk drive. The drive backed by a file on the host system, which can either be a file on a \gls{fs} or point to a block device.
The \gls{OS} running inside a \gls{VM} is typically presented with a virtual disk drive.
The guest \gls{OS} has to implement the driver for this virtual disk drive.
The drive backed by a file on the host system, which can either be a file on a \gls{fs} or point to a block device.
By exclusively assigning one virtual disk drive per \gls{VM}, \glspl{VM} not access other \glspl{VM} data.
As a result, the \gls{hypervisor} features full isolation between guest's \gls{fs} and also prevents them from accessing the host's files.
@ -47,7 +55,8 @@ As a result, the \gls{hypervisor} features full isolation between guest's \gls{f
\label{sect:virt-overhead-app-virt}
Compared to running services directly on the host machine, one obvious overhead is that an additional \gls{OS} is required to be installed and configured once upfront, and virtually booted to enable execution of applications within.
In case that multiple \glspl{VM} are supposed to run the same application, e.g. with different configuration, each of them will have a separate copy of the \gls{OS} and the application itself, differing only by configuration and runtime data.
For this thesis, the use-case is in which solely the applications running on top of the virtualized \gls{OS} is the required subject to gls{virt} is of highest interest. Further the focus lies on applications that can run on \gls{Linux}.
For this thesis, the use-case is in which solely the applications running on top of the virtualized \gls{OS} is the required subject to gls{virt} is of highest interest.
Further the focus lies on applications that can run on \gls{Linux}.
Running a separate virtualized \glspl{OS} in the use-case of virtualizing \gls{Linux} applications involves considerable and unnecessary overhead.
In addition there are several performance aspects that are slowed down when running software inside \Glspl{VM}\cite{Felter2014}.
@ -77,15 +86,16 @@ On \gls{Linux}, there are many different mechanisms to regulate a process's acce
It is important to understand that not all of these mechanisms contribute to security, and that \gls{osvirt} is more difficult to secure compared to \Glspl{VM}.
\subsubsection{The chroot System Functionality}
\label{sect:lpc-chroot}
The oldest mechanism contributing a core functionality to realizing containers is the \textit{change root} functionality\cite{Reshetova2014}.
It allows a privileged process to change its effective root \gls{fs}, which can be any directory on the host.
Effectively every file accessed by path changing the root \gls{fs} will be prefixed with the new root path automatically by the \gls{OS}.
As an example, when a process changes its root \gls{fs} to \textit{/newroot} and then requests to open the file \textit{/file}, the application will transparently access \textit{/newroot/file}.
As a usage example, this allows to easily have a completely separate userspace file structure under \textit{/newroot}.
It could have an application and different libraries installed, which would possibly be in conflict with other libraries if they were installed in the \gls{rootfs} that's in use by host \gls{OS}.
Hence, the chroot-path could contain an application and different libraries installed, which would otherwise be in conflict with other libraries if they were installed in the \gls{rootfs} that's in use by host \gls{OS}.
Note that \textit{chroot} has not been designed as a security feature, so if no countermeasures are taken, privileged \textit{chroot}'ed applications can still access files outside of the chroot-path if they have the intention to.
% TODO practical example?
\subsubsection{Namespaces}
\Glspl{lxns} were designed in 2007 and described as lightweight in-kernel virtualization/isolation\cite{Menage2007}.