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

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

@ -5,13 +5,18 @@ This thesis is a scientific approach to analyze and solve the practical problems
For a lack of an official definition and common understanding what this technology is, the term \gls{sac} is defined in this chapter as a reference for the rest of the thesis.
The technology combines \gls{virt} techniques with new approaches to \gls{app} development and deployment.
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.
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,22 +86,23 @@ 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}.
The authors chose to invent a new name instead of using the descriptive term in order to clarify the distinction from the more heavyweight technology of \gls{VM} \glspl{hypervisor}.
The various \Glspl{lxns} all represent different attributes related to the process and resource model on \gls{Linux}.
Each namespace can contain one or more processes, allowing for arbitrary grouping of processes sharing.
Table \ref{tab:lxns} shows 7 different \Glspl{lxns} that are available at the time of writing.
Table \ref{tab:lxns} shows 7 different \Glspl{lxns} that are available at the time of writing.
Collectively, they represent the context of a process, and changes to resources within the respective namespace will only affect processes that share the same namespace.
\ctable[