50 lines
7 KiB
BibTeX
50 lines
7 KiB
BibTeX
|
Automatically generated by Mendeley Desktop 1.16
|
||
|
|
Any changes to this file will be lost if it is regenerated by Mendeley.
|
||
|
|
|
||
|
|
BibTeX export options can be customized via Options -> BibTeX in Mendeley Desktop
|
||
|
|
|
||
|
|
@inproceedings{Reshetova2014,
|
||
|
|
abstract = {The need for flexible, low-overhead virtualization is evident on many fronts ranging from high-density cloud servers to mobile devices. During the past decade OS-level virtualization has emerged as a new, efficient approach for virtualization, with implementations in multiple different Unix-based systems. Despite its popularity, there has been no systematic study of OS-level virtualization from the point of view of security. In this report, we conduct a comparative study of several OS-level virtualization systems, discuss their security and identify some gaps in current solutions.},
|
||
|
|
archivePrefix = {arXiv},
|
||
|
|
arxivId = {1407.4245},
|
||
|
|
author = {Reshetova, Elena and Karhunen, Janne and Nyman, Thomas and Asokan, N},
|
||
|
|
booktitle = {Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics)},
|
||
|
|
doi = {10.1007/978-3-319-11599-3_5},
|
||
|
|
eprint = {1407.4245},
|
||
|
|
file = {:home/steveej/.local/share/data/Mendeley Ltd./Mendeley Desktop/Downloaded/Reshetova et al. - 2014 - Security of OS-level virtualization technologies(2).pdf:pdf},
|
||
|
|
isbn = {9783319115986},
|
||
|
|
issn = {16113349},
|
||
|
|
pages = {77--93},
|
||
|
|
title = {{Security of OS-level virtualization technologies}},
|
||
|
|
volume = {8788},
|
||
|
|
year = {2014}
|
||
|
|
}
|
||
|
|
@article{Fink2014,
|
||
|
|
abstract = {Docker is a relatively new method of virtualization available natively for 64-bit Linux. Compared to more traditional virtualization techniques, Docker is lighter on system resources, offers a git-like system of commits and tags, and can be scaled from your laptop to the cloud.},
|
||
|
|
author = {Fink, John},
|
||
|
|
file = {:home/steveej/src/github/steveej/msc-thesis/papers/Docker - a Software as a Service, Operating System-Level Virtualization Framework.pdf:pdf},
|
||
|
|
journal = {Code4Lib},
|
||
|
|
number = {25},
|
||
|
|
pages = {3--5},
|
||
|
|
title = {{Docker: a Software as a Service, Operating System-Level Virtualization Framework}},
|
||
|
|
url = {http://journal.code4lib.org/articles/9669},
|
||
|
|
volume = {1},
|
||
|
|
year = {2014}
|
||
|
|
}
|
||
|
|
@book{Utrecht2006,
|
||
|
|
abstract = {Software deployment is the set of activities related to getting$\backslash$r$\backslash$nsoftware components to work on the machines of end users. It includes$\backslash$r$\backslash$nactivities such as installation, upgrading, uninstallation, and so on.$\backslash$r$\backslash$nMany tools have been developed to support deployment, but they all$\backslash$r$\backslash$nhave serious limitations with respect to correctness. For instance,$\backslash$r$\backslash$nthe installation of a component can lead to the failure of previously$\backslash$r$\backslash$ninstalled components; a component might require other components that$\backslash$r$\backslash$nare not present; and it is generally difficult to undo deployment$\backslash$r$\backslash$nactions. The fundamental causes of these problems are a lack of$\backslash$r$\backslash$nisolation between components, the difficulty in identifying the$\backslash$r$\backslash$ndependencies between components, and incompatibilities between$\backslash$r$\backslash$nversions and variants of components.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis thesis describes a better approach based on a purely functional$\backslash$r$\backslash$ndeployment model, implemented in a deployment system called Nix.$\backslash$r$\backslash$nComponents are stored in isolation from each other in a Nix store.$\backslash$r$\backslash$nEach component has a name that contains a cryptographic hash of all$\backslash$r$\backslash$ninputs that contributed to its build process, and the content of a$\backslash$r$\backslash$ncomponent never changes after it has been built. Hence the model is$\backslash$r$\backslash$npurely functional.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThis storage scheme provides several important advantages. First, it$\backslash$r$\backslash$nensures isolation between components: if two components differ in any$\backslash$r$\backslash$nway, they will be stored in different locations and will not overwrite$\backslash$r$\backslash$neach other. Second, it allows us to identify component dependencies.$\backslash$r$\backslash$nUndeclared build time dependencies are prevented due to the absence of$\backslash$r$\backslash$n"global" component directories used in other deployment systems.$\backslash$r$\backslash$nRuntime dependencies can be found by scanning for cryptographic hashes$\backslash$r$\backslash$nin the binary contents of components, a technique analogous to$\backslash$r$\backslash$nconservative garbage collection in programming language$\backslash$r$\backslash$nimplementation. Since dependency information is complete, complete$\backslash$r$\backslash$ndeployment can be performed by copying closures of components under$\backslash$r$\backslash$nthe dependency relation.$\backslash$r$\backslash$n $\backslash$r$\backslash$nDevelopers and users are not confronted with components' cryptographic$\backslash$r$\backslash$nhashes directly. Components are built automatically from Nix$\backslash$r$\backslash$nexpressions, which describe how to build and compose arbitrary$\backslash$r$\backslash$nsoftware components; hashes are computed as part of this process.$\backslash$r$\backslash$nComponents are automatically made available to users through "user$\backslash$r$\backslash$nenvironments", which are synthesised sets of activated components.$\backslash$r$\backslash$nUser environments enable atomic upgrades and rollbacks, as well as$\backslash$r$\backslash$ndifferent sets of activated components for different users.$\backslash$r$\backslash$n $\backslash$r$\backslash$nNix expressions provide a source-based deployment model. However,$\backslash$r$\backslash$nsource-based deployment can be transparently optimised into binary$\backslash$r$\backslash$ndeployment by making pre-built binaries (keyed on their cryptographic$\backslash$r$\backslash$nhashes) available in a shared location such as a network server. This$\backslash$r$\backslash$nis referred to as transparent source/binary deployment.$\backslash$r$\backslash$n $\backslash$r$\backslash$nThe purely functional deployment mo
|
||
|
|
author = {Utrecht, Universiteit and Magnificus, Rector},
|
||
|
|
booktitle = {Utrecht University},
|
||
|
|
doi = {10.1007/s12630-009-9179-6},
|
||
|
|
file = {:home/steveej/src/github/steveej/msc-thesis/papers/nix-phd-thesis.pdf:pdf},
|
||
|
|
isbn = {9039341303},
|
||
|
|
issn = {14968975},
|
||
|
|
number = {12},
|
||
|
|
pages = {0--281},
|
||
|
|
pmid = {19728000},
|
||
|
|
title = {{The Purely Functional Software Deployment Model}},
|
||
|
|
url = {http://www.st.ewi.tudelft.nl/{~}dolstra/pubs/phd-thesis.pdf},
|
||
|
|
volume = {56},
|
||
|
|
year = {2006}
|
||
|
|
}
|