mirror of
https://git.overleaf.com/6227c8e96fcdc06e56454f24
synced 2024-11-22 02:01:48 +00:00
311 lines
12 KiB
TeX
311 lines
12 KiB
TeX
%%
|
|
%% This is file `sample-acmsmall.tex',
|
|
%% generated with the docstrip utility.
|
|
%%
|
|
%% The original source files were:
|
|
%%
|
|
%% samples.dtx (with options: `acmsmall')
|
|
%%
|
|
%% IMPORTANT NOTICE:
|
|
%%
|
|
%% For the copyright see the source file.
|
|
%%
|
|
%% Any modified versions of this file must be renamed
|
|
%% with new filenames distinct from sample-acmsmall.tex.
|
|
%%
|
|
%% For distribution of the original source see the terms
|
|
%% for copying and modification in the file samples.dtx.
|
|
%%
|
|
%% This generated file may be distributed as long as the
|
|
%% original source files, as listed above, are part of the
|
|
%% same distribution. (The sources need not necessarily be
|
|
%% in the same archive or directory.)
|
|
%%
|
|
%% Commands for TeXCount
|
|
%TC:macro \cite [option:text,text]
|
|
%TC:macro \citep [option:text,text]
|
|
%TC:macro \citet [option:text,text]
|
|
%TC:envir table 0 1
|
|
%TC:envir table* 0 1
|
|
%TC:envir tabular [ignore] word
|
|
%TC:envir displaymath 0 word
|
|
%TC:envir math 0 word
|
|
%TC:envir comment 0 0
|
|
%%
|
|
%%
|
|
%% The first command in your LaTeX source must be the \documentclass command.
|
|
\documentclass[sigplan]{acmart}
|
|
%% NOTE that a single column version is required for
|
|
%% submission and peer review. This can be done by changing
|
|
%% the \doucmentclass[...]{acmart} in this template to
|
|
%% \documentclass[manuscript,screen]{acmart}
|
|
%%
|
|
%% To ensure 100% compatibility, please check the white list of
|
|
%% approved LaTeX packages to be used with the Master Article Template at
|
|
%% https://www.acm.org/publications/taps/whitelist-of-latex-packages
|
|
%% before creating your document. The white list page provides
|
|
%% information on how to submit additional LaTeX packages for
|
|
%% review and adoption.
|
|
%% Fonts used in the template cannot be substituted; margin
|
|
%% adjustments are not allowed.
|
|
%%
|
|
%% \BibTeX command to typeset BibTeX logo in the docs
|
|
\AtBeginDocument{%
|
|
\providecommand\BibTeX{{%
|
|
\normalfont B\kern-0.5em{\scshape i\kern-0.25em b}\kern-0.8em\TeX}}}
|
|
|
|
%% Rights management information. This information is sent to you
|
|
%% when you complete the rights form. These commands have SAMPLE
|
|
%% values in them; it is your responsibility as an author to replace
|
|
%% the commands and values with those provided to you when you
|
|
%% complete the rights form.
|
|
\setcopyright{acmcopyright}
|
|
\copyrightyear{2022}
|
|
\acmYear{2022}
|
|
\acmDOI{XXXXXXX.XXXXXXX}
|
|
|
|
|
|
%%
|
|
%% These commands are for a JOURNAL article.
|
|
\acmJournal{JACM}
|
|
\acmVolume{37}
|
|
\acmNumber{4}
|
|
\acmArticle{111}
|
|
\acmMonth{8}
|
|
|
|
%%
|
|
%% Submission ID.
|
|
%% Use this when submitting an article to a sponsored event. You'll
|
|
%% receive a unique submission ID from the organizers
|
|
%% of the event, and this ID should be used as the parameter to this command.
|
|
%%\acmSubmissionID{123-A56-BU3}
|
|
|
|
%%
|
|
%% The majority of ACM publications use numbered citations and
|
|
%% references. The command \citestyle{authoryear} switches to the
|
|
%% "author year" style.
|
|
%%
|
|
%% If you are preparing content for an event
|
|
%% sponsored by ACM SIGGRAPH, you must use the "author year" style of
|
|
%% citations and references.
|
|
%% Uncommenting
|
|
%% the next command will enable that style.
|
|
%%\citestyle{acmauthoryear}
|
|
|
|
%%
|
|
%% Personal package imports
|
|
\usepackage{listings}
|
|
|
|
%%
|
|
%% end of the preamble, start of the body of the document source.
|
|
\begin{document}
|
|
|
|
%%
|
|
%% The "title" command has an optional parameter,
|
|
%% allowing the author to define a "short title" to be used in page headers.
|
|
\title[Multi-Entrypoint Applications]{Multi-Entrypoint Applications: allowing the binary to self-regulate an application deployment with multiple levels of privilege separation}
|
|
|
|
%%
|
|
%% The "author" command and its associated commands are used to define
|
|
%% the authors and their affiliations.
|
|
%% Of note is the shared affiliation of the first two authors, and the
|
|
%% "authornote" and "authornotemark" commands
|
|
%% used to denote shared contribution to the research.
|
|
\author{Jake Hillion}
|
|
\affiliation{%
|
|
\institution{University of Cambridge}
|
|
}
|
|
\email{jake.hillion@cl.cam.ac.uk}
|
|
|
|
%%
|
|
%% By default, the full list of authors will be used in the page
|
|
%% headers. Often, this list is too long, and will overlap
|
|
%% other information printed in the page headers. This command allows
|
|
%% the author to define a more concise list
|
|
%% of authors' names for this purpose.
|
|
%\renewcommand{\shortauthors}{Hillion}
|
|
|
|
%%
|
|
%% The abstract is a short summary of the work to be presented in the
|
|
%% article.
|
|
\begin{abstract}
|
|
Operating systems are providing more facilities for process isolation than ever before, realised in technologies such as Containers [CN] and systemd slices [CN]. These systems separate the design of the program from the systems that create privilege separation.
|
|
|
|
Multi-Entrypoint Applications bring the privilege separation back into the program itself. By using a trusted shim and binfmt\_misc [CN], an application started with minimal privileges can achieve full separation. High-level language features provide an easy interface to privilege separation.
|
|
|
|
I present a summary of the privilege separation features in modern Linux, the system design of multi-entrypoint applications, the language front-ends to support it, and an evaluation on a series of example applications.
|
|
\end{abstract}
|
|
|
|
%%
|
|
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
|
|
%% Please copy and paste the code instead of the example below.
|
|
%%
|
|
\begin{CCSXML}
|
|
<ccs2012>
|
|
<concept>
|
|
<concept_id>10010520.10010553.10010562</concept_id>
|
|
<concept_desc>Computer systems organization~Embedded systems</concept_desc>
|
|
<concept_significance>500</concept_significance>
|
|
</concept>
|
|
<concept>
|
|
<concept_id>10010520.10010575.10010755</concept_id>
|
|
<concept_desc>Computer systems organization~Redundancy</concept_desc>
|
|
<concept_significance>300</concept_significance>
|
|
</concept>
|
|
<concept>
|
|
<concept_id>10010520.10010553.10010554</concept_id>
|
|
<concept_desc>Computer systems organization~Robotics</concept_desc>
|
|
<concept_significance>100</concept_significance>
|
|
</concept>
|
|
<concept>
|
|
<concept_id>10003033.10003083.10003095</concept_id>
|
|
<concept_desc>Networks~Network reliability</concept_desc>
|
|
<concept_significance>100</concept_significance>
|
|
</concept>
|
|
</ccs2012>
|
|
\end{CCSXML}
|
|
|
|
\ccsdesc[500]{Computer systems organization~Embedded systems}
|
|
\ccsdesc[300]{Computer systems organization~Redundancy}
|
|
\ccsdesc{Computer systems organization~Robotics}
|
|
\ccsdesc[100]{Networks~Network reliability}
|
|
|
|
%%
|
|
%% Keywords. The author(s) should pick words that accurately describe
|
|
%% the work being presented. Separate the keywords with commas.
|
|
\keywords{datasets, neural networks, gaze detection, text tagging}
|
|
|
|
|
|
%%
|
|
%% This command processes the author and affiliation and title
|
|
%% information and builds the first part of the formatted document.
|
|
\maketitle
|
|
|
|
\section{Introduction}
|
|
|
|
TODO
|
|
|
|
\section{Motivation}
|
|
|
|
TODO
|
|
|
|
\subsection{Threat Model}
|
|
|
|
I present a threat model in which application binaries are trusted absolutely. That is, the software provider had no ill intent, and once the binary is on disk, it will not change without permission. This means that one can trust the binary to set up its own security, as it is protecting not against malice by its own developers, but instead bugs in the software.
|
|
|
|
\section{Background}
|
|
|
|
TODO
|
|
|
|
\subsection{File Descriptor Passing}
|
|
\label{section:file-descriptor-passing}
|
|
|
|
TODO
|
|
|
|
\section{System Design}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=\columnwidth]{figures/self-compartmentalisation.png}
|
|
\caption{Interaction between the application and the environment.}
|
|
\label{fig:self-compartmentalisation-interactions}
|
|
\end{figure}
|
|
|
|
The multi-entrypoint application shim creates an object capability out of process creation.
|
|
|
|
\section{Language Frontends}
|
|
|
|
TODO
|
|
|
|
\subsection{Rust}
|
|
|
|
\lstset{language=C,caption={A sample application using the Rust language frontend.}}
|
|
\begin{lstlisting}[float]
|
|
#[entrypoint]
|
|
fn main() {
|
|
let input_file = ...;
|
|
let output_file = ...;
|
|
|
|
encrypt(input_file, output_file);
|
|
}
|
|
|
|
#[entrypoint]
|
|
fn encrypt(mut in: File, mut out: File)
|
|
\end{lstlisting}
|
|
|
|
\section{Example Applications}
|
|
|
|
\subsection{No Permissions}
|
|
|
|
The cornerstone of strong process separation is an application that is completely deprivileged.
|
|
|
|
\lstset{language=C,caption={An application that requires only stdout and stderr.}}
|
|
\begin{lstlisting}[float]
|
|
#[entrypoint(stdout,stderr)]
|
|
fn main() { println!("hello world!"); }
|
|
\end{lstlisting}
|
|
|
|
\subsection{gzip}
|
|
|
|
GNU gzip \citep{gailly_gzip_2020} is well structured for privilege separation, though doesn't implement it by default. There is a clear split between the processing logic, selecting the items to do work on, and the compression/decompression routines, each of which are handed a pair of input and output file descriptors. This is shown by Watson et al. in \cite{watson_capsicum_2010}.
|
|
|
|
As C is not an adapted language for multi-entrypoint applications, adapting it is slightly more verbose than the other examples seen. However, the resulting code change is still only X lines, if a bit more intricate. This places the risky compression and decompression routines in full sandboxes, while still allowing the simpler argument processing code ambient authority. The argument processing code needs no additional permissions to be able to handle this permissioning, as the required permissions are provided by the shim.
|
|
|
|
\subsection{TLS Server}
|
|
|
|
TODO
|
|
|
|
\section{Evaluation}
|
|
|
|
TODO
|
|
|
|
\section{Related Work}
|
|
|
|
\subsection{Virtual Machines and Containers}
|
|
|
|
Virtual Machine solutions \citep{barham_xen_2003,vmware_inc_understanding_2008} provide the ability to split a single machine into multiple virtual machines. When placing a single application in each virtual machine, they are effectively isolated from one another. Full fat container solutions such as Docker [CN], containerd [CN], and systemd-nspawn [CN] provide mechanisms to isolate an application almost completely from other applications running on a single machine. Some have claimed that this provides isolation superior to virtual machines \citep{soltesz_container-based_2007}.
|
|
|
|
Container solutions are less effective at isolating parts of an application from itself [CN with research].
|
|
|
|
\subsection{systemd}
|
|
|
|
\texttt{systemd} [CN] provides a declarative interface to all of the process separation techniques used in this work. Rather than the responsibility of the programmer, creating these declarative descriptions is most commonly left to the package maintainers. This work seeks to provide similar capabilities to the people best suited to privilege separating an application: the developers.
|
|
|
|
\subsection{Capsicum}
|
|
|
|
Capsicum \citep{watson_capsicum_2010} extends UNIX file descriptors in FreeBSD to reflect the rights on the object they hold. These capabilities may be shared between processes as other file descriptors (§\ref{section:file-descriptor-passing}). The goals of both software are the same: make privilege separated software better. However, we take quite different approaches. Multi-entrypoint applications focus on building a static definition really close to the code, while Capsicum allows processes to dynamically privilege separate. This allows applying static analysis to the policies, while also keeping the definition close to the code.
|
|
|
|
\section{Future Work}
|
|
|
|
\subsection{Dynamic Linking}
|
|
|
|
TODO
|
|
|
|
\section{Conclusion}
|
|
|
|
TODO
|
|
|
|
%%
|
|
%% The acknowledgments section is defined using the "acks" environment
|
|
%% (and NOT an unnumbered section). This ensures the proper
|
|
%% identification of the section in the article metadata, and the
|
|
%% consistent spelling of the heading.
|
|
\begin{acks}
|
|
TODO: acknowledgements
|
|
\end{acks}
|
|
|
|
%%
|
|
%% The next two lines define the bibliography style to be used, and
|
|
%% the bibliography file.
|
|
\bibliographystyle{ACM-Reference-Format}
|
|
\bibliography{references}
|
|
|
|
%%
|
|
%% If your work has an appendix, this is the place to put it.
|
|
\appendix
|
|
|
|
\end{document}
|
|
\endinput
|
|
%%
|
|
%% End of file `sample-acmsmall.tex'.
|