diff --git a/src/docs/parts/context/context.tex b/src/docs/parts/context/context.tex
index 6306b4f..e70620b 100644
--- a/src/docs/parts/context/context.tex
+++ b/src/docs/parts/context/context.tex
@@ -98,6 +98,7 @@ Note that \textit{chroot} has not been designed as a security feature, so if no
 
 
 \subsubsection{Namespaces}
+\label{sect:lpc-ns}
 \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}.
@@ -137,10 +138,17 @@ Collectively, they represent the context of a process, and changes to resources
     Mount points, /proc/self/mountinfo
 }
 
-% TODO example how to further isolate filesystem access/view for chrooted process
-% TODO practical example?
+To continue the example given in section \ref{sect:lpc-chroot}, assuming that a \textit{chroot()} call took place, an application that lies within this chroot-path is going to be executed.
+The resulting application, executed through the process that also called \textit{chroot()}, could be further isolated from the outer system by moving the process to a new set of \gls{lxns} before executing the application.
+Particularly interesting for this example is the perspective of a new \textbf{Mount}-Namespace, since it further contributes to aspect of filesystem isolation.
+Manipulations to the mount points made within the new namespace will not affect other processes on the system.
+This is effective for protecting against error cases like, accidental file deletions, but can be considered an initial level of security as the mounts are not propagated to the parent process, allowing the management and usage of specific resources only within a specific set of processes.
+
+As an example, an application could mount a secured file-resource within the new mount-namespace, and no other process on the system would be able to find this resource by simply searching their view of the filesystem nor by examining the mount table.
+If another process is then moved to this mount-namespace it could automatically access the secured filessytem, without the need of having the secrets for and the accomplishment of the mount procedure.
 
 \subsubsection{Capabilities}
+\label{sect:lpc-caps}
 \Glspl{lxcap} provide a mechanism for fine-grained permission control for \gls{Linux} processes and programs files.\cite{Hallyn2008}.
 Conventionally, applications that require elevated privileges are started by \textit{root\footnote{the administrator account on \gls{Linux}}}.
 By dropping specific unneeded capabilities, the risk of running an applications that needs some but not all of the \textit{root} privileges can be heavily reduced.
@@ -169,10 +177,12 @@ By dropping specific unneeded capabilities, the risk of running an applications
 At the time of writing \gls{Linux} the 39 capabilities that are known are listed in table \ref{tab:lxns}.
 They are listed explicitly for the sake of completeness, and as a demonstration of how many different privileges are distinguished today on \gls{Linux}.
 
-It is not important to understand each and every listed \gls{lxcap} for this document.
-The highlighted \textit{CAP\_SYS\_CHROOT} serves as a simple example of security potential.
-When this capability is dropped after executing the \textit{chroot()} syscall, it is not possible for the executed application to call \textit{chroot()} again.
-% TODO practical example?
+As the focus for this project is not \gls{appc} per-se, but only the method of creation and form of distribution, it is not important to examine every listed \gls{lxcap}, but rather look at an interesting example.
+The highlighted \textit{CAP\_SYS\_CHROOT} serves well here for demonstrating the security potential and further extending the example that has been used in \ref{sect:lpc-chroot} and \ref{sect:lpc-ns}.
+
+After a successful \textit{chroot()}-call and switch to a new mount-namespace, there is still the chance that the process has kept or retrieves a reference to a file on the outside.
+This reference can be used to escape the chroot by issuing another \textit{chroot()} syscall to the topmost parent of said file, which is likely the host's root.
+When \textit{CAP\_SYS\_CHROOT} is dropped after executing the \textit{chroot()} syscall, the kernel will not permit the executed application to call \textit{chroot()} again, and can hereby effectively prevent the escape.
 
 \subsubsection{Control Groups}
 % TODO