diff --git a/src/docs/glossary.tex b/src/docs/glossary.tex index f667225..f1cf358 100644 --- a/src/docs/glossary.tex +++ b/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}{ - name = Linux Capabilities, +\newglossaryentry{lxcap}{ + 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}{ diff --git a/src/docs/parts/context/context.tex b/src/docs/parts/context/context.tex index 9326368..34ed968 100644 --- a/src/docs/parts/context/context.tex +++ b/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} -% TODO +\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. + +\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}.