thesis: add capabilities overview

src/docs/glossary.tex

@@ -66,6 +66,13 @@
     plural=Linuces
 }
 
+\newglossaryentry{rootfs}{
+    name = RootFS,
+    description = {
+        % TODO
+    },
+}
+
 \newglossaryentry{lxns}{
     name = Linux Namespace,
     description = {
@@ -73,11 +80,19 @@
     },
 }
 
-\newglossaryentry{lxcaps}{
+\newglossaryentry{lxcap}{
-    name = Linux Capabilities,
+    name = Linux Capability,
     description = {
         entitiy that holds a specific set of process attributes and can be set per process, mainly to establish a relationship between processes and \gls{OS} resources
     },
+    plural = Linux Capabilities,
+}
+
+\newglossaryentry{lxvfs}{
+    name = Linux VFS,
+    description = {
+        Virtual Filesystem Switch, a filesystem abstraction layer in \gls{Linux}.
+    },
 }
 
 \newglossaryentry{BSD}{

src/docs/parts/context/context.tex

@@ -74,15 +74,18 @@ With \gls{osvirt}, the control as well as the responsibility for the virtualized
 In contrast to running an application inside a \gls{VM}, where the host \gls{OS} doesn't know anything beyond the border of the process that runs the \gls{VM} and has no direct control over the application processes inside the \gls{VM}.
 
 On \gls{Linux}, there are many different mechanisms to regulate a process's access or its view on resources of all kinds.
-It is important to understand 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}
-The oldest one contributing one of the core functionalities to realize 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.
 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}.
 
-Note that \textit{chroot} has not been designed as a security feature, and therefore privileged \textit{chroot}'ed applications can easily access the host's filesystem if no countermeasures are taken.
+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}.
@@ -96,7 +99,7 @@ Collectively, they represent the context of a process, and changes to resources
     cap = \Glspl{lxns},
     caption = \Glspl{lxns}\footnote{from \textit{NAMESPACES(7)} and \textit{UNSHARE(2)}},
     maxwidth = \textwidth,
-    label = tab:lxns
+    label = tab:lxns,
     ]{l | X}{}{
 \FL
     Namespace & Resources
@@ -120,13 +123,46 @@ Collectively, they represent the context of a process, and changes to resources
     User & 
     UIDs, GIDs, capabilities
 \NN
-    Mount &
+    \textbf{Mount} &
     Mount points, /proc/self/mountinfo
 }
 
+% TODO example how to further isolate filesystem access/view for chrooted process
+% TODO practical example?
+
 \subsubsection{Capabilities}
-\Glspl{lxcaps} \cite{Hallyn2008}
+\Glspl{lxcap} provide a mechanism for fine-grained permission control for \gls{Linux} processes and programs files.\cite{Hallyn2008}.
-% TODO
+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.
+
+\ctable[
+    cap = \Glspl{lxcap},
+    caption = \Glspl{lxcap}\footnote{from \textit{CAPABILITIES(7)}},
+    maxwidth = \textwidth,
+    label = tab:lxcap,
+    ]{c}{}{
+\FL CAP\_AUDIT\_CONTROL, CAP\_AUDIT\_READ, CAP\_AUDIT\_WRITE
+\NN CAP\_BLOCK\_SUSPEND, CAP\_CHOWN, CAP\_DAC\_OVERRIDE
+\NN CAP\_DAC\_READ\_SEARCH, CAP\_FOWNER, CAP\_FSETID
+\NN CAP\_IPC\_LOCK, CAP\_IPC\_OWNER, CAP\_KILL
+\NN CAP\_LEASE, CAP\_LINUX\_IMMUTABLE, CAP\_MAC\_ADMIN
+\NN CAP\_MAC\_OVERRIDE, CAP\_MKNOD, CAP\_NET\_ADMIN
+\NN CAP\_NET\_BIND\_SERVICE, CAP\_NET\_BROADCAST, CAP\_NET\_RAW
+\NN CAP\_SETGID, CAP\_SETFCAP, CAP\_SETPCAP
+\NN CAP\_SETUID, CAP\_SYS\_ADMIN, CAP\_SYS\_BOOT
+\NN \textbf{CAP\_SYS\_CHROOT}, CAP\_SYS\_MODULE, CAP\_SYS\_NICE
+\NN CAP\_SYS\_PACCT, CAP\_SYS\_PTRACE, CAP\_SYS\_RAWIO
+\NN CAP\_SYS\_RESOURCE, CAP\_SYS\_TIME, CAP\_SYS\_TTY\_CONFIG
+\NN CAP\_SYSLOG, CAP\_WAKE\_ALARM, CAP\_SETPCAP
+}
+
+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?
 
 \subsubsection{Control Groups}
 % TODO
@@ -139,7 +175,7 @@ Collectively, they represent the context of a process, and changes to resources
 \subsubsection{Initialization And Combination Of The Above}
 When \gls{Linux} is booted, an initial set of namespaces, cgroups, and security contexts are created to contain the first userspace process, typically called init.
 
-Depending on the nature and configuration of the init process, other \glspl{app} are created with a new set of namespaces and cgroups, inherit all or only a selected set from the init process.
+Depending on the program and configuration of the init process, other \glspl{app} are created with a new set of namespaces and cgroups, inherit all or only a selected set from the init process.
 The two concepts can be mingled since the mechanisms allow for a flexible configuration per process.
 This functionality is exposed via the \gls{Linux} systemcall \gls{API}.