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 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. 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 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}} \chapter{\Gls{virt}}
\label{chap: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 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 \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. 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}} \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. 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} \subsection{\Gls{fs} Storage Isolation}
\label{sect:vm-fs-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. 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. 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} \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. 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. 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. 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}. 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}. 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} \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}. 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. 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}. 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 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}. 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. 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} \subsubsection{Namespaces}
\Glspl{lxns} were designed in 2007 and described as lightweight in-kernel virtualization/isolation\cite{Menage2007}. \Glspl{lxns} were designed in 2007 and described as lightweight in-kernel virtualization/isolation\cite{Menage2007}.