[lemona commit] r438 - in docs/publications/thesis: . msc-thesis-2008 msc-thesis-2008/images msc-thesis-2008/imag...

[codesite...@google.com]

Author: laurent.malvert
Date: Sat Nov 15 22:13:14 2008
New Revision: 438

Added:
docs/publications/thesis/
docs/publications/thesis/msc-thesis-2008/
docs/publications/thesis/msc-thesis-2008/images/
docs/publications/thesis/msc-thesis-2008/images/workflow/
docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendices.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-a.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-b.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-c.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.bib
docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-conclusion.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-discussion.tex

docs/publications/thesis/msc-thesis-2008/lemona-thesis-experimentation.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-introduction.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-methodology.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.bib
docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-related-work.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-abstract.tex

docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknowledgments.tex

docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknownledgments.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-summary.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title.tex
docs/publications/thesis/msc-thesis-2008/lemona-thesis.tex
docs/publications/thesis/msc-thesis-2008/template-ieee.tex
docs/publications/thesis/msc-thesis-2008/template-thesis.tex

Log:
* added folder for thesis publications
* added sub folder for the 2008 MSc thesis
* added all TeX files for the MSc thesis

* TODO:
* thesis:
* fix bug with appendices
* revamp methodology and experimentation sections
* proofread
* take screenshots of the build
* take screenshots of the boot process
with Lemona's messages
* export images to .eps level 3
* regenerate PDF thesis and upload it here
* update the thesis' wiki page
* others:
* upload the 2008.11.12 (laurent) and 2008.11.14 (mika) presentations
* correct the IT-SOFT 2008 paper's mistakes
* correct the IT-SOFT 2008's wiki page


Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendices.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendices.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,15 @@
+\appendix
+\noappendicestocpagenum
+\addappheadtotoc
+
+% Adjustments headers
+\pagestyle{fancy}
+\fancyhead[LO]{\leftmark}
+\fancyhead[RE]{\emph{Appendix \thechapter}}
+\renewcommand{\headrulewidth}{0.5pt}
+
+% appendices here
+
+\input{lemona-thesis-appendix-a}
+\input{lemona-thesis-appendix-b}
+\input{lemona-thesis-appendix-c}

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-a.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-a.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,3 @@
+\chapter{Source Code}
+
+source code goes here.

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-b.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-b.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,2 @@
+\chapter{Inputs / Outputs}
+

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-c.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-appendix-c.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,10 @@
+\chapter{Screenshots}
+
+\section{Build Process}
+
+%TODO: insert screen captures of the build process here
+
+\section{Boot Process}
+
+%TODO: insert screen captures of the boot process with lemona enabled
+%here

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.bib
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.bib
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,350 @@
+@article{
+aranya:TRACEFS,
+ Author = {Aranya, A. and Wright, C. P. and Zadok, E.},
+ Title = {Tracefs: A File System to Trace Them All},
+ Year = {2004} }
+
+
+
+@article{
+balon:CIF,
+ Author = {Balon, N. and Stovall, R. and Scaria, T.},
+ Title = {Computer Intrusion Forensics Research Paper},
+ Year = {} }
+
+
+
+@article{
+bauer:SYSLOG,
+ Author = {Bauer, M.},
+ Title = {Paranoid Penguin: syslog Configuration},
+ Journal = {Linux Journal},
+ Volume = {2001},
+ Number = {92},
+ Year = {2001} }
+
+
+
+@article{
+cantrill:DIPS,
+ Author = {Cantrill, B. M. and Shapiro, M. W. and Leventhal, A. H.},
+ Title = {Dynamic instrumentation of production systems},
+ Year = {2004} }
+
+
+
+@article{
+cornell:WAYBACK,
+ Author = {Cornell, B. and Dinda, P. A. and Bustamante, F. E.},
+ Title = {Wayback: A User-level Versioning File System for Linux},
+ Journal = {Proceedings of Usenix Annual Technical Conference, FREENIX
Track},
+ Pages = {19–28},
+ Year = {2004} }
+
+
+
+@article{
+desnoyers:LTTNG,
+ Author = {Desnoyers, M. and Dagenais, M. R.},
+ Title = {The lttng tracer: A low impact performance and behavior
monitor for GNU/Linux},
+ Journal = {OLS (Ottawa Linux Symposium)},
+ Pages = {209–224},
+ Year = {2006} }
+
+
+
+@article{
+dunlap:REVIRT,
+ Author = {Dunlap, G. W. and King, S. T. and Cinar, S. and Basrai, M. A.
and Chen, P. M.},
+ Title = {ReVirt: enabling intrusion analysis through virtual-machine
logging and replay},
+ Journal = {ACM SIGOPS Operating Systems Review},
+ Volume = {36},
+ Pages = {211-224},
+ Year = {2002} }
+
+
+
+@misc{
+eigler:SYSTEMTAP,
+ Author = {Eigler, F. C. and Prasad, V. and Cohen, W. and Nguyen, H. and
Hunt, M. and Keniston, J. and Chen, B.},
+ Title = {Architecture of systemtap: a Linux trace/probe tool},
+ URL = {http://sourceware.org/systemtap/archpaper.pdf},
+ Year = {2005} }
+
+
+
+@article{
+garfinkel:TRAPS,
+ Author = {Garfinkel, T.},
+ Title = {Traps and Pitfalls: Practical Problems in System Call
Interposition Based Security Tools},
+ Journal = {Proceedings of the Network and Distributed Systems Security
Symposium},
+ Year = {2003} }
+
+
+
+@article{
+goel:FORENSIX,
+ Author = {Goel, A. and Feng, W. C. and Maier, D. and Walpole, J.},
+ Title = {Forensix: a robust, high-performance reconstruction system},
+ Journal = {Distributed Computing Systems Workshops, 2005. 25th IEEE
International Conference on},
+ Pages = {155-162},
+ Year = {2005} }
+
+
+
+@article{
+hiramatus:DJPROBE,
+ Author = {Hiramatsu, M. and Oshima, S.},
+ Title = {Djprobe—Kernel probing with the smallest overhead},
+ Journal = {Linux Symposium},
+ Year = {2007} }
+
+
+
+@article{
+keniston:PTRACE,
+ Author = {Keniston, J. and Mavinakayanahalli, A. and Panchamukhi, P.
and Prasad, V.},
+ Title = {Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User
Apps},
+ Journal = {Linux Symposium},
+ Year = {2007} }
+
+
+
+@article{
+king:BACKTRACKING,
+ Author = {King, S. T. and Chen, P. M.},
+ Title = {Backtracking intrusions},
+ Journal = {ACM Transactions on Computer Systems (TOCS)},
+ Volume = {23},
+ Number = {1},
+ Pages = {51-76},
+ Year = {2003} }
+
+
+
+@article{
+knight:VULNERABILITIES,
+ Author = {Knight, E.},
+ Title = {Computer Vulnerabilities},
+ Year = {2000} }
+
+
+
+@article{
+krishnakumar:KPROBE,
+ Author = {Krishnakumar, R.},
+ Title = {Kernel korner: kprobes-a kernel debugger},
+ Journal = {Linux Journal},
+ Volume = {2005},
+ Number = {133},
+ Year = {2005} }
+
+
+
+@misc{
+sun:VIRTUALBOX,
+ Author = {Microsystems, S.},
+ Title = {VirtualBox},
+ URL = {http://www.virtualbox.org},
+ Year = {} }
+
+
+
+@article{
+pohlack:RTSMON,
+ Author = {Pohlack, M. and Dobel, B. and Lackorzynski, A.},
+ Title = {Towards Runtime Monitoring in Real-Time Systems},
+ Journal = {Proceedings of the Eighth Real-Time Linux Workshop},
+ Year = {2006} }
+
+
+
+@article{
+rekhis:TADISI,
+ Author = {Rekhis, S.},
+ Title = {Theoretical Aspects of Digital Investigation of Security
Incidents},
+ Year = {} }
+
+
+
+@article{
+rogers:FORENSICS,
+ Author = {Rogers, M.},
+ Title = {COMPUTER FORENSICS: EVIDENCE HANDLING & MANAGEMENT},
+ Year = {} }
+
+
+
+@article{
+salvador:IDS,
+ Author = {Salvador, J. A. F.},
+ Title = {An intrusion detection system based in the gathering of Linux
Syslog Logs from Linux, Windows NT and Snort},
+ Year = {2003} }
+
+
+
+@article{
+sarmoria:MMF,
+ Author = {Sarmoria, C. G. and Chapin, S. J.},
+ Title = {Monitoring access to shared memory-mapped files},
+ Journal = {Proc. of the 2005 Digital Forensics Research Workshop
(DFRWS). New Orleans},
+ Year = {2005} }
+
+
+
+@article{
+spitzner:KYE,
+ Author = {Spitzner, L.},
+ Title = {Know Your Enemy: A Forensic Analysis},
+ Journal = {URL:
http://www.securityfocus.com/focus/ih/articles/foranalysis.html},
+ Year = {2000} }
+
+
+
+@article{
+stallings:NETCRYPTO,
+ Author = {Stallings, W.},
+ Title = {Cryptography and Network Security},
+ Year = {2003} }
+
+
+
+@article{
+tan:READINESS,
+ Author = {Tan, J.},
+ Title = {Forensic Readiness},
+ Journal = {The CanSecWest Computer Security Conference, April},
+ Year = {2001} }
+
+
+
+@article{
+wisniewski:MULTIPROC,
+ Author = {Wisniewski, R. W. and Rosenburg, B.},
+ Title = {Efficient, Unified, and Scalable Performance Monitoring for
Multiprocessor Operating Systems},
+ Journal = {Supercomputing, 2003 ACM/IEEE Conference},
+ Pages = {3-3},
+ Year = {2003} }
+
+
+
+@article{
+zanussi:RELAYFS,
+ Author = {Zanussi, T. and Yaghmour, K. and Wisniewski, R. and Moore, R.
and Dagenais, M.},
+ Title = {relayfs: An Efficient Unified Approach for Transmitting Data
from Kernel to User Space},
+ Journal = {Linux Symposium},
+ Year = {2003} }
+
+
+
+@article{
+mohan:REPOFS,
+ Author = {Mohan, P. and Aanjhan, R.},
+ Title = {Mounting of Version Control Repositories: RepoFS},
+ Journal = {High Performance Computing-HiPC 2006},
+ Year = {2006} }
+
+
+
+@article{
+letscher:CARBON,
+ Author = {Letscher, D.},
+ Title = {Carbon Copy Filesystem: A Real Time Snapshot Filesystem Layer},
+ Year = {2006} }
+
+
+
+@misc{
+sun:ZFS,
+ Author = {Microsystems, S.},
+ Title = {ZFS: The last word in file systems},
+ Year = {} }
+
+
+
+@misc{
+vmware,
+ Author = {VMWare, Inc.},
+ Title = {VM Ware},
+ URL = {http://www.vmware.com},
+ Year = {} }
+
+
+
+@misc{
+symantec:GHOST,
+ Author = {Sysmantec, Corp.},
+ Title = {Norton Ghost},
+ URL = {http://www.symantec.com/norton/ghost},
+ Year = {} }
+
+
+
+@misc{
+cederqvist:CVS,
+ Author = {Cederqvist, P.},
+ Title = {Version Management with CVS},
+ Publisher = {Network Theory Ltd.},
+ Year = {2002} }
+
+
+
+@book{
+collins-sussman:SVN,
+ Author = {Collins-Sussman, B. and Fitzpatrick, B. W. and Pilato, C. M.},
+ Title = {Version Control with Subversion},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2004} }
+
+
+
+@article{
+BAZAAR,
+ Title = {Bazaar Distributed VCS},
+ Year = {} }
+
+
+
+@misc{
+GIT,
+ Title = {Git},
+ URL = {http://git.or.cz/},
+ Year = {} }
+
+
+
+@misc{
+osullivan:MERCURIAL,
+ Author = {O’Sullivan, B.},
+ Title = {Distributed revision control with Mercurial},
+ Year = {2006} }
+
+
+
+@book{
+love:LINUXSYSPROG,
+ Author = {Love, Robert},
+ Title = {Linux System Programming: Talking Directly to the Kernel and C
Library},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2007} }
+
+
+
+@book{
+bovet:ULK,
+ Author = {Bovet, D. P. and Cesati, M.},
+ Title = {Understanding the Linux Kernel},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2005} }
+
+
+
+@book{
+mitnick:DECEPTION,
+ Author = {Mitnick, K. D. and Simon, W. L.},
+ Title = {The Art of Deception: Controlling the Human Element of
Security},
+ Publisher = {Wiley},
+ Year = {2002} }
+
+
+

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-bibliography.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,6 @@
+\newpage
+\pagestyle{plain}
+\addcontentsline{toc}{chapter}{Bibliography}
+\bibliographystyle{elsart-harv-ms}
+\bibliography{lemona-thesis-bibliography}
+\newpage

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-conclusion.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-conclusion.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,86 @@
+\chapter{Conclusion}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Sub-Table of Content
+% 1- Outcomes
+% 2- Future Work
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+Our paper posed the general environment of computer forensics
+analysis, and introduced \textbf{Lemona}, our solution for a
+monitoring architecture relying on open standards and implementations,
+and aiming towards the post-mortem investigation of compromised
+systems.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Outcomes
+\section{Outcomes}
+
+As we demonstrated with the presentation of \textbf{Lemona}'s
+performance and settings, its design allows it to theoretically trace
+and record the complete activity at the lowest architectural level of
+an operating system, permitting a global review of the system's life,
+while managing to impact the system with an acceptable overhead, thus
+remaining satisfyingly usable and available.
+
+In the long run, \textbf{Lemona} will not only allow a forensics
+investigator to determine how and when an attack occured, but also
+offer the possibility to review the compromised or exploited resources
+and reconstruct the system based on the fine-grained and exhaustive
+records it generates, replaying the compromised system's lifecycle
+step by step.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Future Work
+\section{Future Work}
+
+There are countless possible improvements to \textbf{Lemona}, three of
+which are listed below. It could benefit of numerous other variants,
+which are currently being studied.
+
+\subsection{IDS/IPS Integration}
+
+Conceptualy, \textbf{Lemona} might as well be used as an
+\emph{IPS}/\emph{IDS} or interoperate with one. This would of course
+require the dynamic analysis of the monitored information. To have
+\textbf{Lemona} act as or collaborate with an \emph{IDS}, it would
+require its full tracing/reporting/analysis/response process to be
+completed in near real-time. Furthermore, to turn \textbf{Lemona} in
+or have it operate with an \emph{IPS}, then it would require this same
+process to be \emph{atomic} and \emph{real-time}, as we discussed
+earlier in our "related work" section. Both solutions would also
+require \textbf{Lemona} to be packaged and/or communicate with a
+database of exploits' workflows.
+
+\subsection{Improvements to the Static Statistical Analyzer}
+
+There are many methods to analyze traces of a monitored system. The
+flow of \emph{system calls} can for instance be compared to a database
+of well-known exploits, as stated earlier. We could then use pattern
+matching techniques to identify attacks spread over longer
+timeframes. Several pattern detection mechanisms would be suitable for
+this purpose, though they might not be usable in an \emph{atomic} and
+\emph{real-time} scheme to turn \textbf{Lemona} into an
+\emph{IPS}. They would however be very useful to reduce the noise in
+the traces and analyze brand new vulnerabilities.
+
+The analyzer could also rely on new geometrical analysis
+methods. These methods typically imply the representation of the
+host's activity as a mathematical curve or geometric form, which can
+then be compared to a database of preset forms matching the exploits'
+database.
+
+\subsection{Design Decisions}
+
+\textbf{Lemona} is a brand new project and its design is still
+morphing, both at the low and high levels of the
+architecture. \textbf{Lemona} is not designed for performance at the
+moment because of the radical changes it goes through on a regular
+basis.
+
+We consider revisiting our design to integrate more dynamic and
+generic solutions, that would alleviate both the burden of the
+developers to integrate new patches and the amount of complexity
+required to set up the system.

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-discussion.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-discussion.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,80 @@
+\chapter{Discussion}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Sub-Table of Content
+% 1- Findings
+% 2- Limitations
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Findings
+\section{Findings}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Limitations
+\section{Limitations}
+
+\textbf{Lemona}, though designed to be a more complete monitoring
+facility than the existing solutions, is of course not
+foolproof. These are the various ways that we could think of so far to
+circumvent its surveillance, or render it inefficient.
+
+\subsection{Break the Pipe or Break the Storage Point}
+
+If the connection between \textbf{Lemona}'s storage point and the
+\textbf{Lemona}-enabled monitored host can be severed, then of course
+the system will not be able to be recovered from future crashes.
+
+Similarly, an attacker could get control over the storage point, which
+mean he or she could not only prevent monitoring of malicious
+activities, but also destroy already collected evidence or recovery
+data, and erase tracks of its presence.
+
+Possible solutions to this problem reside in the hardening of the
+transfer connections and host systems, and maybe also in the use of
+multiple storage points and connections. There is however no
+completely foolproof solution to this issue, and there will not ever
+be one, neither with \textbf{Lemona} or any other system.
+
+\subsection{Stuck the Pipe}
+
+If an attacker can somehow manage to block outgoing connections or to
+overflow the network's throughput, then he or she may be able to
+perform malevolent activities that will not have the time to be
+reported to the storage point before the system is brought to an
+unrecoverable crash or before he can tamper with \textbf{Lemona}'s
+system.
+
+A solution to this issue would be to force the system to attribute the
+highest priority to outgoing packets emitted by the \textbf{Lemona}
+reporting components. This is technically possible, but we have not
+implemented such a feature so far.
+
+This problem can also occur if \textbf{Lemona} is running on a machine
+with a very high traffic load, such as a web-server hosting a
+corporate or e-commerce website. The combination of the
+\textbf{Lemona}'s auditing throughput and the normal server load might
+reach the bandwidth limitation, and \textbf{Lemona}'s reporting could
+be delayed, thus allowing an attacker to exploit a vulnerability and
+crash the system without it showing in the logs.
+
+A correct adjustement to the load-balancing taking into consideration
+the web-server's network load theoretically overcomes this problem.
+
+\subsection{Break Lemona}
+
+It is actually possible that an attacker, who would succeed in
+performing a privilege escalation, might render \textbf{Lemona}
+unusable. If combined with one of the previous method, it means the
+system will not be monitored anymore. If it is not, then it means we
+will still be able to review the attack procedure used by the
+attacker, but we will not be able to examine the data that was
+compromised once \textbf{Lemona} was taken down. This could be a
+problem if an organization needs to assert its losses and their
+criticality.
+
+There is no real solution to avoid this. \textbf{Lemona} is enabled on
+a host, and if the host can be compromised, so can be the tracing and
+reporting modules.

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-experimentation.tex
==============================================================================
--- (empty file)
+++
docs/publications/thesis/msc-thesis-2008/lemona-thesis-experimentation.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,336 @@
+\chapter{Experimentation}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Sub-Table of Content
+% 1- Experimental Setup
+% 2- Experimental Procedure
+% 2- Results
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Experimental Setup
+
+\section{Experimental Setup}
+
+\subsection{Test Configuration}
+
+The results have been gathered using the following configuration:
+
+\begin{itemize}
+ \item \textbf{CPU:} Intel(R) Pentium(R) M processor 1.80GHz
+ \item \textbf{RAM:} 1GB
+ \item \textbf{OS:} GNU/Linux Gentoo
+ \begin{itemize}
+ \item \textbf{CFLAGS:} -O2 -march=pentium-m -pipe -fomit-frame-pointer
+ \end{itemize}
+ \item \textbf{VM:} VirtualBox-2.0.4
+ \begin{itemize}
+ \item \textbf{Guest OS:} Linux Gentoo
+ \item \textbf{Base Memory:} 256MB
+ \item \textbf{Video Memory:} 16MB
+ \item \textbf{Network:} PCnet-FAST III (host interface, tap0)
+ \end{itemize}
+\end{itemize}
+
+There are two different batteries of tests to demonstrate the capabilities
+of the \textbf{Lemona} system:
+
+\begin{itemize}
+ \item Performance \& Availability Benchmarks
+ \item Functional Tests
+\end{itemize}
+
+
+All tests have been carried using a statically compiled lemona module
+using different configurations:
+
+\begin{itemize}
+ \item lemona + net
+
+ The network module is enabled, but there is no server to send data to.
+
+ \item lemona + net + basket
+
+ The network module is enabled and the \emph{basket} server is
+ accepting data.
+
+ \item lemona + relay
+
+ The \emph{kernel}'s relay facility is enabled, but no program is
+ reading the output.
+
+ \item lemona + relay + cat
+
+ The \emph{kernel}'s relay facility is enabled and the output is read
+ by cat to \emph{/dev/null}.
+\end{itemize}
+
+
+\subsection{Performance \& Availability Benchmarks}
+
+These benchmarks aim to demonstrate the usability of \textbf{Lemona} in a
+test environment, by proving that its performance impact does not render
+the system unavailable.
+
+We want to check the performance impact of the \textbf{Lemona} system for
+"standard" system usage, based on tests presented by \textbf{Forensix}
\cite{goel:FORENSIX}:
+
+\begin{itemize}
+ \item benchmarking the build of a Linux \emph{kernel} from scratch
+ \item benchmarking the throughput of an \textbf{Apache Web Server}.
+\end{itemize}
+
+Each benchmark set is carried using 12 different configurations:
+
+\begin{itemize}
+ \item \textbf{Lemona} has neither been built, nor loaded
+ \item \textbf{Lemona} has been built as a module, but the module is not
loaded
+ \item \textbf{Lemona} has been built as a module and the module has been
loaded:
+ \begin{itemize}
+ \item Relay reporting is enabled / Socket reporting is disabled
+ \item Relay reporting is disabled / Socket reporting is enabled with
encryption
+ \item Relay reporting is disabled / Socket reporting is enabled
without encryption
+ \item Relay and Socket reporting are enabled (with encryption)
+ \item Relay and Socket reporting are enabled (without encryption)
+ \end{itemize}
+ \item \textbf{Lemona} has been built statically:
+ \begin{itemize}
+ \item Relay reporting is enabled / Socket reporting is disabled
+ \item Relay reporting is disabled / Socket reporting is enabled with
encryption
+ \item Relay reporting is disabled / Socket reporting is enabled
without encryption
+ \item Relay and Socket reporting are enabled (with encryption)
+ \item Relay and Socket reporting are enabled (without encryption)
+ \end{itemize}
+\end{itemize}
+
+Recorded information for the performance benchmarks include:
+
+\begin{itemize}
+ \item timestamps for:
+ \begin{itemize}
+ \item benchmark start
+ \item benchmark end
+ \item each of the following readings
+ \end{itemize}
+ \item regular and peak readings for:
+ \begin{itemize}
+ \item I/O throughput levels (in bits per seconds)
+ \item CPU consumption levels (in percentage of available processing
power)
+ \item Memory consumption levels (in bytes and percentage of available
memory)
+ \item database inputs (in records per minutes)
+ \item average and peak log file sizes
+ \item average and total number of database entries
+ \end{itemize}
+\end{itemize}
+
+\subsection{Functional Tests}
+
+These tests aim to demonstrate the functional feasibility of
\textbf{Lemona}
+within a real-life environment. Using real case scenarios (yet to be
+determined), the application will be tested to assert:
+
+\begin{itemize}
+ \item \textbf{Lemona}'s capacity at collecting relevant information
+
+ Information relative to security breaches or system failures should
+ be recorded on the host targeted and stored in the database to be
+ identified easily for later forensics research.
+
+ \item \textbf{Lemona}'s capacity at retrieving relevant information
+
+ The information collected during the first phase of the test should
+ be easily and quickly accessed using appropriate queries.
+\end{itemize}
+
+Recorded information for the functional tests include:
+
+\begin{itemize}
+ \item timestamps for:
+ \begin{itemize}
+ \item benchmark start
+ \item benchmark end
+ \item each of the following actions upon start and completion
+ \end{itemize}
+ \item readings for:
+ \begin{itemize}
+ \item returned noise and false positives (absolute and relative
reading)
+ \item lookup time (in seconds)
+ \end{itemize}
+\end{itemize}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Experimental Procedure
+
+\section{Experimental Procedure}
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Results
+
+\section{Results}
+
+\subsection{Notes on the \textbf{Lemona} Results}
+
+As of this writing, results are still being collected. We are just
+providing below some insights on our expectations and our
+checkpoints, as well as the current results we managed to collect.
+
+Currently, we have not collected the results for the functional tests
+outlined above, as \textbf{Lemona} is not feature complete from the
computer
+forensics point of view, and we did not perform tests with an active
+encryption layer, as it is not yet part of our proof of concept.
+
+Regarding the benchmark comparison with \textbf{Forensix}, we would
+like to emphasize that they might not be easy to compare with a 1-to-1
+ratio, for the following reasons:
+
+\begin{itemize}
+ \item \textbf{Coverage}
+
+ \textbf{Forensix} does not record every single operation, and only
+ focuses on specific processes, whereas \textbf{Lemona} aims at
+ monitoring the complete system activity. On the other hand,
+ \textbf{Lemona} does not (yet) monitor all the \emph{system calls};
+ but the ones implemented are monitored for all processes.
+
+ \item \textbf{Hardware and Software Configurations}
+
+ We do not have at our disposal the hardware resources to perform
+ tests matching these of \textbf{Forensix}. Therefore, we use
+ different hardware and system configurations, and our tests were run
+ within a \emph{virtual machine}.
+
+ \item \textbf{Tests Replicability}
+
+ \textbf{Lemona} and \textbf{Forensix} are compared based on similar
+ actions, but with different inputs. For instance, they used
+ different kernel sources for the performance test, which means that
+ the kernel compilation time might not be as relevant.
+
+\end{itemize}
+
+However, we believe these benchmarks provide a valuable insight and
+indication of \textbf{Lemona}'s usability on a real system, and that
+the transparence we provide with this comparison \textbf{Forensix}
+might allow readers to determine if our solution matches their needs.
+
+\subsection{Coverage}
+
+We intend to cover close to 100\% of a system's activity, in that we
+actually trace all existing \emph{system calls} and monitor memory
+mapped areas' read and write accesses. We should therefore be able to
+monitor all actions executed by all (human and machine) users logged
+onto a system as the system's core activity. We expect to be able to
+collect enough data to virtually reconstruct a complete system from a
+given checkpoint.
+
+Our proof of concept achieves a technical validation of this
+objective, by monitoring twenty-two (22) \emph{system calls}, among
+which some of the most intensive ones, performing I/O operations.
+
+\subsection{Performance}
+
+\subsubsection{CPU: Linux Kernel 2.6.26.3 Compilation}
+
+The kernel has been compiled using the configuration file found in
+\emph{arch/x86/configs/i386\_defconfig\_} that comes along with its
+sources.
+
+Between each test:
+
+\begin{itemize}
+ \item the virtual machine has been reset
+ \item the 'old' Linux directory has been deleted and copied over again.
+\end{itemize}
+
+For each test \emph{make menuconfig} has been executed before
+launching the compilation. No modification has been made to the
+default configuration, we simply have him save the \emph{.config}
+file.
+
+We use the \emph{time make} command to produce the following
+measurements.
+
+\begin{table}
+ \renewcommand{\arraystretch}{1.3}
+ \caption{Performance Results}
+ \label{table:performance}
+ \centering
+ \begin{tabular}{ | l | l | l | l | l | }
+ \hline
+ \textbf{Test} & \textbf{User Time} &
\textbf{System Time} & \textbf{Real Time} & \textbf{CPU} \\ \hline
+ \textbf{w/o lemona} & 283s &
226s & 519s & 98\% \\ \hline
+ \textbf{w/ lemona + net} & 242s &
256s & 531s (+02.31\%) & 93\% \\ \hline
+ \textbf{w/ lemona + net + basket} & 269s &
334s & 670s (+29.09\%) & 90\% \\ \hline
+ \textbf{w/ lemona + relay} & 300s &
292s & 604s (+16.37\%) & 98\% \\ \hline
+ \textbf{w/ lemona + relay + cat} & 247s &
256s & 1028s (+98.07\%) & 49\% \\ \hline
+ \hline
+ \end{tabular}
+\end{table}
+
+As we predicted, we notice a significant impact on the system's
+performance when \textbf{Lemona} is enabled. However, and even though
+\textbf{Lemona} performs worse than \textbf{Forensix} (See Appendix
+A), our proof of concept remains usable inspite of the overhead.
+
+\subsubsection{Network: Apache 2 Benchmark}
+
+An \textbf{Apache 2} server has been installed, default configuration has
+been kept, and a 169 bytes \emph{index.html} file created.
+
+The benchmark has been done using the 'ab' tool from the
+\textbf{Apache Foundation} as follows:
+
+\begin{verbatim}
+ab -n 10000 -c 10 http://10.0.42.2/
+\end{verbatim}
+
+\begin{table}
+ \renewcommand{\arraystretch}{1.3}
+ \caption{Network Results}
+ \label{table:network}
+ \centering
+ \begin{tabular}{ | l | l | l | l | }
+ \hline
+ \textbf{Test} & \textbf{Total Time} &
\textbf{Requests/s} & \textbf{Real Time} \\ \hline
+ \textbf{w/o lemona} & 5.767s &
1733.97 & 687.49Kb \\ \hline
+ \textbf{w/ lemona + net} & 5.977s (+03.64\%) & 1673.00
(-03.51\%) & 663.32Kb (-03.51\%) \\ \hline
+ \textbf{w/ lemona + net + basket} & 6.912s (+19.85\%) & 1446.73
(-16.56\%) & 573.61Kb (-16.56\%) \\ \hline
+ \textbf{w/ lemona + relay} & 6.091s (+05.61\%) & 1641.63
(-05.32\%) & 650.88Kb (-05.32\%) \\ \hline
+ \textbf{w/ lemona + relay + cat} & 6.700s (+16.17\%) & 1492.50
(-13.92\%) & 591.75Kb (-13.92\%) \\ \hline
+ \hline
+ \end{tabular}
+\end{table}
+
+As for the CPU consumption, the network resources take a significant
+hit if \textbf{Lemona} is configured to transmit its traces over the
+network. Considering \textbf{Lemona} will be transmitting all the
+traces over a network interface, it will be under considerable
+load. However, we might implement buffering techniques to improve
+this, and we think the solution should provide satisfactory results to
+be used on a \emph{LAN}. Benchmarks will show if this is a viable
+solution for systems residing on more distant networks, such as
+\emph{WAN}/\emph{VPNs}.
+
+\subsubsection{Memory}
+
+As of today, the tracing structures' memory footprint is less than 30
+bytes, if they do not require additional parameters. Regarding the
+memory consumption on the storage point's side, which we expect to
+have a high rate, we are not able at the moment to provide valuable
+benchmarks, for various reasons, which are explained below.
+
+\begin{itemize}
+ \item \textbf{Lemona}'s internal storage structures are morphing because:
+ \begin{itemize}
+ \item We are still in the process of modifying our API;
+ \item They depend on which system call is being traced.
+ \end{itemize}
+ \item The rate at which the traces will be generated is really variable
because:
+ \begin{itemize}
+ \item It depends on the kind of load the monitored host is being put
under;
+ \item It depends on the kind of activity the monitored host is
performing (watching a movie or doing a full-text search will not have the
same system call throughputs)
+ \end{itemize}
+\end{itemize}

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-introduction.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-introduction.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,351 @@
+\chapter{Introduction}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Sub-Table of Content
+% 1- Scope
+% 2- Background
+% 3- Research Problem / Significance
+% 4- Outline
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Scope
+\section{Scope}
+
+The \textbf{Lemona} project aims at providing a secure, complete and
+efficient mean of monitoring a computer system. Related papers and
+projects referenced in this document are based mostly on Linux- and
+UNIX-based systems, although most of the concepts are applicable to
+other operating systems. Thus, references made to the "\emph{kernel}"
+or "system" should be interpreted as being Linux when not otherwise
+specified.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Background
+\section{Background}
+
+\subsection{Cyber-Criminality}
+
+Over the last decades, companies and individuals have undergone a
+shift from legacy information processing systems to computerized
+information systems. This trend largely impacts the usage and access
+policies of valuable assets. Unfortunately, the modern enterprise and
+private models of information processing are as exposed as their
+ancestors, and we recognize a matching raise of cyber-robbery and
+malevolent misuse.
+
+
+\subsection{Computer Forensics}
+
+Forensic science (commonly referred to as simply "forensics"), aims to
+answer questions asked by the legal system to establish the liability
+of individuals in relation to criminal acts. It naturally encompasses
+what we call computer forensics, which is a specific branch pertaining
+to legal evidence being looked for and examined in digital systems.
+
+Computer forensic science mostly aims at collecting digital evidence
+to prove the ownership and retransmission of illegal information by an
+individual, or to recreate and prove the logical course of action
+followed by an attacker while providing proof of the attacker's
+wrongdoing. In doing so, a forensics analysis determines the course of
+actions which led to the state of a digital artifact. Such an artifact
+can be either a storage media or a static or mobile piece of
+electronic information (for instance an electronic document or a
+sequence of network packets).
+
+Examples of typical case studies and illegal activities are diverse
+\cite{knight:VULNERABILITIES}:
+
+\begin{itemize}
+ \item network intrusions;
+ \item corruption of private or corporate data;
+ \item stealing of private or corporate data;
+ \item the publication and storage of illegal content.
+\end{itemize}
+
+The role of the forensics expert, in a legal context, is to provide
+\cite{balon:CIF}:
+
+\begin{itemize}
+ \item the technical information bound to the criminal act;
+ \item the skills and technological background to understand its
surroundings;
+ \item evidence of the absence or presence of the crime.
+\end{itemize}
+
+Considering this setting, it means computer forensics analysis has to
+be led following a very strict, professional and documented
+protocol. In effect, every action of the forensics team has to be
+recorded and should prove the validity of its method and its results.
+
+
+\subsection{Evidence}
+
+When a team of computer forensics experts conducts the analysis of a
+digital crime scene, it faces several challenges, which constitute a
+critical path to the acceptance of any potential evidence produced as
+an outcome \cite{rogers:FORENSICS}:
+
+\begin{itemize}
+ \item Admissible
+ \begin{itemize}
+ \item Must be able to be used in court or elsewhere;
+ \end{itemize}
+ \item Authentic
+ \begin{itemize}
+ \item Evidence relates to incident in relevant way;
+ \end{itemize}
+ \item Complete (no tunnel vision)
+ \begin{itemize}
+ \item Exculpatory evidence for alternative suspects;
+ \end{itemize}
+ \item Reliable
+ \begin{itemize}
+ \item No question about authenticity \& veracity;
+ \end{itemize}
+ \item Believable
+ \begin{itemize}
+ \item Clear, easy to understand, and believable by a jury.
+ \end{itemize}
+\end{itemize}
+
+While computer forensics is not an entirely new field per se, there
+are still gray areas in its legal definition and
+application. Therefore, it is important to pay crucial attention to
+the details of the forensics analysis setting and its execution.
+
+In addition, a company who wants to protect its digital assets might
+want to reuse various components of an Information Security Management
+System or a similar framework, destined to prevent the destruction
+and/or stealth of its corporate information, and to facilitate its
+recovery, should the worst happen.
+
+Such concerns, though not addressed in this document, are in close
+relationship with its content, as some of the elements described in
+existing specifications of such frameworks are part of the general
+concepts of computer forensics we describe, or applied by the
+solutions we review.
+
+In the context of a company in the position of building a legally
+receivable case, the questions we aim to ask and answer in this paper
+are the following:
+
+\begin{itemize}
+ \item What information is available on a common system (default
installation)?
+ \item What information should be collected?
+ \item How can this information be collected?
+ \item How can this information be stored?
+ \item How can this information be transferred?
+ \item What impact will be induced on system performance by the gathering
of information?
+\end{itemize}
+
+This brings us to consider the various elements of a forensics analysis
system:
+
+\begin{itemize}
+ \item The data source/host system,
+ \item The data samples themselves,
+ \item The data storage system.
+\end{itemize}
+
+These questions have several aspects pertaining to the collected
+information (the "data"), regarding its court wise validity and value:
+
+\begin{itemize}
+ \item Exhaustiveness,
+ \item Integrity,
+ \item Confidentiality,
+ \item Reliability.
+\end{itemize}
+
+These values match the CIA elements (see Figure \ref{fig:fig1}).
+
+\begin{figure}
+ \begin{centering}
+ \centering
+
\includegraphics[scale=0.40]{images/security/lemona-security-concepts-cia.png}
+ \caption{The CIA Elements of Security}
+ \label{fig:fig1}
+ \end{centering}
+\end{figure}
+
+\subsection{Threats and Countermeasures}
+
+\subsubsection{Intrusions}
+
+Before going further, let us quickly explain what type of intrusion
+and attacks a computer system can be exposed to and what can we do,
+from a forensics point-of-view, to detect these attacks.
+
+William Stallings defined three distinct types of Computer Intrusion
+\cite{stallings:NETCRYPTO}:
+
+\paragraph{Masquerader}
+
+An individual who is not authorized to use the computer and who
+penetrates a system's access controls to exploit a legitimate user
+account.
+
+\paragraph{Misfeasor}
+
+A legitimate user who accesses data, programs, or resources for
+which such access is not authorized, or who is authorized for such
+access but misuses his or her privileges.
+
+\paragraph{Clandestine User}
+
+An individual who seizes supervisory control of the system and uses
+this control to evade auditing and access controls or to suppress
+audit collection.
+
+\subsubsection{Vulnerabilities}
+
+In 2000, Eric Knight gave an exhausting list of Computer
+Vulnerabilities \cite{knight:VULNERABILITIES}, although time has
+passed they are still the same nowadays:
+
+\paragraph{Logic Errors}
+
+Mistakes in the design of the software that allows a security breach.
+
+\paragraph{Social Engineering}
+
+\begin{itemize}
+ \item "Art of personal manipulation"
+ \item "Human Element of Security" \cite{mitnick:DECEPTION}
+\end{itemize}
+
+\paragraph{Computer Weakness}
+
+Very similar to vulnerabilities, the difference being that weaknesses
+might never have a resolution (e.g. encryption key size).
+
+\paragraph{Policy Oversights}
+
+Does not necessarily involve people, can be simple "Act of God" such
+as fire or hardware failures.
+
+\paragraph{Faults}
+
+Commonly known as bugs, or human errors.
+
+\begin{figure}
+ \begin{centering}
+ \centering
+
\includegraphics[scale=0.40]{images/security/lemona-security-concepts-threats.png}
+ \caption{Common Threats}
+ \label{fig:fig2}
+ \end{centering}
+\end{figure}
+
+\subsubsection{Aftermath}
+
+When one of the above vulnerabilities is successfully applied to
+perform an intrusion, computer forensics is used to
+\cite{tan:READINESS, balon:CIF, rekhis:TADISI}:
+
+\begin{itemize}
+ \item assess that an intrusion has happened;
+ \item determine what has been affected;
+ \item examine the circumstances and causes.
+\end{itemize}
+
+In order to do so, evidences can be collected from various sources
+\cite{tan:READINESS, balon:CIF}:
+
+\begin{itemize}
+ \item Memory Units:
+ \begin{itemize}
+ \item Hard Drives,
+ \item Random Access Memory,
+ \item External Memory Units,
+ \end{itemize}
+ \item System Logs,
+ \item Network Traffic,
+ \item IDS (both NIDS, HIDS),
+ \item Physical Security.
+\end{itemize}
+
+However, on a default system only System Logs level would be
+available. Unfortunately, they can be easily modified by the attacker
+and are not configured to log as many data as possible by default and
+these are often not kept long enough or in a secure location. On the
+other hand, \emph{IDS} and Physical Security when installed and
+correctly configured can cut down forensics investigation time in half
+\cite{tan:READINESS}.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Research Problem
+\section{Research Problem}
+
+A post-mortem forensics system shall allow investigators to examine
+targeted systems (or a legally valid reproduction) after their
+decommission or destruction. Therefore, whether the system and its
+data can still be accessed or not, and whether the attack covered or
+not the tracks of his intrusion, does not have any value.
+
+To obtain these capabilities, a system must be permanently
+scrutinized, with the lowest level of monitoring possible, so that
+each and every one of a user's activities is exhaustively logged. Such
+a level of granularity allows the forensics team to reproduce step by
+step specific time periods of the life of the now defunct system, and
+to determine how it was eventually taken down. If such a solution
+looks perfect from a theoretical standpoint, there are nonetheless
+some problems to take into consideration:
+
+\begin{itemize}
+ \item negative performance impact on the target operating system;
+ \item high network bandwidth consumption;
+ \item high storage memory requirements;
+ \item privacy concerns;
+ \item broad-to-fine granularity adjustments;
+ \item practical usability of the logs and traces.
+\end{itemize}
+
+Therefore, a post-mortem forensics analysis shall be designed with
+performance and security concerns in mind. It ought to provide an
+acceptable mix of fine-grained monitoring and flexibility to produce a
+viable system, both from the users' point of view (in terms of speed
+and responsiveness) and from the forensics analysts' point of view (in
+terms of legal acceptance and recognition of the collected data as
+potential evidence).
+
+Those are the reasons for the creation of \textbf{Lemona}, which is
+intended to draft an architecture relying on open communication,
+encryption and logging standards. Following these architecture
+specifications, \textbf{Lemona} designs and implements a decentralized
+post-mortem forensics analysis system. This platform should be capable
+of providing fine-grained logging capabilities to all parts of a
+system and reporting it to secure storage points for further
+examination, while maintaining the system's usability, building upon
+the empirical research provided by similar projects.
+
+\begin{figure}
+ \begin{centering}
+ \centering
+
\includegraphics[scale=0.60]{images/architecture/lemona-architecture-2.png}
+ \caption{Lemona's Standard Use Case}
+ \label{fig:fig3}
+ \end{centering}
+\end{figure}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Outline
+\section{Outline}
+
+Our goal in the first part of this article is to present the current
+state of the forensics software market regarding post-mortem analysis
+tools. We will briefly review in the "Related Work" section the latest
+literature and project research that we have been basing our research
+on to confirm or infirm our results and design decisions.
+
+We will then expose this design by detailing in the "Lemona" section
+our software solution and its architecture, as well as the current
+state of its implementation. We will then expose and explain the
+results we have obtained so far.
+
+Finally, we would like to discuss the possible improvements that could
+be brought to \textbf{Lemona} and other alternatives directions we are
+in the process of experimenting with.

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-methodology.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-methodology.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,390 @@
+\chapter{Methodology}
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Sub-Table of Content
+% 1- Background
+% 2- Architecture
+% 3- Algorithms
+% 4- Implementation
+% 5- Controls
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Background
+
+\section{Background}
+
+\subsection{System Calls}
+
+In computer systems, the \emph{kernel} is the main component of the
+operating system. It is the piece of software in charge of managing
+the system resources (i.e. communicating with the hardware
+devices). Being the lowest abstraction layer between software and
+hardware, every operation needing support from the underlying hardware
+or requesting to update the hardware's state will go through it.
+
+Thus, applications that need to access the hardware use the
+\emph{kernel} layer interface: the \emph{system calls} (commonly
+called \emph{syscalls}). \emph{Syscalls} are functions invoked by user
+applications to request some service or resource from the
+\emph{kernel} \cite{love:LINUXSYSPROG}.
+
+With this in mind, it is obvious that it is possible to have a
+complete monitoring of what applications request to do with the
+resources of the computer system by adding logging mechanisms at the
+entrance and exit of these functions.
+
+\subsection{Scheduler}
+
+We have seen that we can monitor access to the computer system's
+resources by simply logging the usage of the \emph{kernel}
+\emph{syscalls}. However, due to the nature of the \emph{kernel}, we
+need to capture log from other parts of the \emph{kernel} to be able
+to draw a timeline of an application's execution, namely the ones in
+charge of allocating time slices to applications: the
+\emph{scheduler}. The \emph{scheduler} is the part of the
+\emph{kernel} deciding who can access the CPU at a given moment in
+time and for how long. While a system gives the illusion of having
+several applications running concurrently - multi-processor systems
+aside - actually only one single process can make use of the CPU at
+any given moment. The \emph{scheduler} allocates a tiny amount of time
+to each application which leads to this illusion of concurrency
+\cite{bovet:ULK}.
+
+\subsection{Memory Mapping}
+
+Monitoring \emph{syscalls} permits to see easily every change made to
+files on disk. However, modern \emph{kernel}s give the possibility to
+an application to map files in memory by using the mmap
+\emph{syscall}. This allows an application to access directly the
+content of a file as if it was part of its own memory space
+(i.e. without having to issue the corresponding \emph{syscall} when it
+needs to read or write to it). It also permits to reduce the
+performance impact on data manipulation and moves by avoiding the
+intermediate copy of the data in a \emph{kernel} buffer. Every time
+the application will try to access a part of the file not yet mapped
+into memory, the system will emit a so-called Page Fault. This event
+will suspend the application execution and inform the \emph{kernel}
+that the application tried to read or write a yet unmapped
+position. Then the \emph{kernel} will load the relevant data into
+memory and allow the application to resume its execution, starting
+over from the point preceding the \emph{Page Fault}. The application
+can now read or write from or to the portion of the file as
+intended. In order to log the data modified and accessed by this kind
+of application, it is thus necessary to alter the part of the
+\emph{kernel} in charge of handling Page Faults in addition to the
+logging of the mmap related \emph{syscalls}.
+
+Because these file portions are loaded using the granularity of a
+so-called \emph{Page Size} (usually 4 Kilobytes), the logging
+mechanism is bound to use the same. This is translated by the fact
+that the logging of the changes made to a portion of the file can only
+be done when the application is removed from the CPU by the
+\emph{scheduler}. Doing so earlier would not guarantee that every
+changes made to a given portion (page) of the file will be logged.
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Architecture
+
+\section{Architecture}
+
+\begin{figure}
+ \centering
+
\includegraphics[scale=0.40]{images/architecture/lemona-architecture-5.png}
+ \caption{Lemona's Architecture}
+ \label{fig:fig4}
+\end{figure}
+
+\textbf{Lemona} is a compound of several components (Figure
+\ref{fig:fig3} and Figure \ref{fig:fig4}), separated in three
+categories:
+
+\begin{figure}
+ \centering
+
\includegraphics[scale=0.55]{images/architecture/lemona-architecture-components.png}
+ \caption{Lemona's Components}
+ \label{fig:fig5}
+\end{figure}
+
+\subsection{Monitoring Components}
+
+\subsubsection{Kernel Patches}
+
+These are alterations to the Linux Kernel codebase needed to monitor
+\emph{syscalls} entry and exit points, as well as application
+scheduling and memory mapped files related \emph{Page Faults}. The
+patches are designed to allow a literate user to remove the
+\textbf{Lemona} functionalities (and thus their processing overhead
+and memory footprint) from the \emph{kernel} if he chooses to disable
+it upon compilation.
+
+\subsubsection{Loadable Kernel Modules}
+
+While the patches add code at key \emph{kernel} points for logging,
+the driver does the actual logging. It structures the logged
+information and sends the result to the various designated
+backends. Even Though we made it possible to dynamically load and
+unload the \textbf{Lemona} functionalities, we only did so to
+facilitate debugging and initial testing, or for end-users
+convenience. However, administrators of production systems should
+build the module statically for security reasons. This will for
+instance avoid early logs to be lost.
+
+So far, the modules can only transmit the generated logs via two
+different methods:
+
+\begin{itemize}
+ \item Via an (un)encrypted socket
+ \item Via the kernel's relay functionality
+\end{itemize}
+
+It is important to note that data can easily be lost using any of
+these techniques. In the first case, if the server does not answer or
+is too slow to treat the data, incoming log data will be simply
+drop. The same applies to the relay facility. Once the buffers are
+full, new incoming logs will be discarded until the user application
+processes enough data to free up one or more buffers.
+
+\paragraph{Socket Method}
+
+Upon startup, the module will prompt the user for the passphrase used
+to encrypt sent to the logging server. Alternatively, this passphrase
+could be stored on the local file system for automatic startup; but
+this increase the security risk. If the link to the server is
+considered sure enough, it is possible to disable the encryption
+mechanism and thus reduce the CPU consumption impact of
+\textbf{Lemona}.
+
+\paragraph{Kernel Relay Method}
+
+This method exists mainly for testing purposes. Using the relay
+functionality of the \emph{kernel}, the logs are made available to
+user space applications using the debugfs file system. User
+applications are then free to transfer the data back to a logging
+server or on a local database.
+
+\subsection{Logging Components}
+
+\subsubsection{Databases Servers}
+
+SQL databases are used to stock the logs, making it easy for forensics
+expert to query them and request specific data. This allows for quick
+access to relevant informational datasets, and for easy and flexible
+narrowing of the search domain (e.g. by date, applications,
+etc...). Depending on the database server used on the backend, useful
+requests could be recorded for future reference. In addition, we plan
+to rely heavily on database caching mechanisms to speed up information
+retrieval.
+
+\subsubsection{Logging Servers}
+
+This application is in charge of receiving the logs from the
+\emph{kernel}. Upon startup, the \textbf{Lemona} driver will connect
+to the logging server and start sending him data as it comes
+through. In order to maximize throughput, the server should preferably
+be directly connected to the monitoring machine via a fast link
+(i.e. Gigabit Ethernet). For security reasons, the machine hosting the
+server should be hardened, and avoid unnecessary services should be
+disabled and uninstalled altogether.
+
+The server application is actually a compound of two programs. The
+first one is in charge of receiving the data sent by the driver. It
+immediately appends the data to a set of buffer files without any
+modification. Once a file is full, another one is created. The second
+application will read already filled files, decrypt them and insert
+the data in the database. This architecture avoids heavy slowdowns
+upon data reception by delegating the load of the decryption (if any)
+on the receiving application.
+
+\subsection{Forensics Component}
+
+\subsubsection{Database-Querying Applications}
+
+We are currently working on a querying application to provide simple
+interactive access to the database data. This application should
+permit the creation of specific queries without the user having to
+know the database schema. It would present the output in a meaningful
+way targeted at forensics expert.
+
+This part of the \textbf{Lemona} architecture is still under heavy
+R\&D though.
+
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Algorithms
+
+\section{Algorithms}
+
+% TODO
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Implementation
+
+\section{Implementation}
+
+\begin{verbatim}
+extern atomic_t lemona_activated;
+static lemonalogfn _lemona_log = NULL;
+
+# define lemona_block_start \
+ if (atomic_read(&lemona_activated) != 0) \
+ {
+
+# define lemona_log_in(sysnr, argnr, extnr, ...) \
+ __lemona_log(sysnr, true, argnr, extnr, ## __VA_ARGS__)
+
+# define lemona_log_out(sysnr, argnr, extnr, ...) \
+ __lemona_log(sysnr, false, argnr, extnr, ## __VA_ARGS__)
+
+# define lemona_block_end \
+ } \
+ else { \
+ _lemona_log = NULL; \
+ }
+
+#define __lemona_log(sysnr, in, argnr, extnr, ...) { \
+ if (_lemona_log == NULL) \
+ _lemona_log = (lemonalogfn)kallsyms_lookup_name("lemona_log"); \
+ _lemona_log(sysnr, in, argnr, extnr, ## __VA_ARGS__); \
+}
+\end{verbatim}
+
+\begin{verbatim}
+extern atomic_t lemona_activated;
+static lemonalogfn _lemona_log = NULL;
+
+# define lemona_block_start \
+ if (atomic_read(&lemona_activated) != 0) \
+ {
+
+# define lemona_log_in(sysnr, argnr, extnr, ...) \
+ __lemona_log(sysnr, true, argnr, extnr, ## __VA_ARGS__)
+
+# define lemona_log_out(sysnr, argnr, extnr, ...) \
+ __lemona_log(sysnr, false, argnr, extnr, ## __VA_ARGS__)
+
+# define lemona_block_end \
+ } \
+ else { \
+ _lemona_log = NULL; \
+ }
+
+#define __lemona_log(sysnr, in, argnr, extnr, ...) { \
+ if (_lemona_log == NULL) \
+ _lemona_log = (lemonalogfn)kallsyms_lookup_name("lemona_log"); \
+ _lemona_log(sysnr, in, argnr, extnr, ## __VA_ARGS__); \
+}
+\end{verbatim}
+
+\lstset{language=C}
+\begin{lstlisting}
+struct lemona_zest {
+ char magic[4];/* magic number */
+ int size; /* size taken by this zest and args sz/value */
+
+ int in; /* input or output ? */
+ struct timespec time; /* call start/end time (getnstimeofday) */
+
+ pid_t pid; /* actual pid */
+ pid_t tgid; /* thread group id */
+
+ uid_t uid,euid,fsuid; /* user identification numbers */
+ gid_t gid,egid,fsgid; /* group identification numbers */
+
+ int sysnr; /* syscall id */
+ int argnr; /* number of args */
+
+ int *argsz; /* ptr to an array of int giving each arg size */
+ void *args; /* ptr to the first argument of the array */
+
+ int extnr; /* extra value number */
+ int *extsz; /* size of each extension */
+ void *exts; /* extra values. located after the last arg */
+} __attribute__((packed));
+\end{lstlisting}
+
+\begin{lstlisting}
+struct lemona_mixer {
+ int sysnr; /* system call number */
+ struct __lemona_mixer in; /* call entrance mixer */
+ struct __lemona_mixer out; /* call exit mixer */
+}
+
+struct __lemona_mixer {
+ int argnr; /* number of syscall parameters */
+ int extnr; /* number of extra parameters */
+ struct __lemona_mixer_handler handlers[6]; /* pre-defined handlers */
+};
+
+struct __lemona_mixer_handler {
+ bool dual; /* is this a dual blade? */
+ bladefn blade; /* number of extra parameters */
+};
+
+typedef int (*bladefn)(struct lemona_zest *zest, /* zest to fill */
+ int isExt, /* is an extra? */
+ int idx, /* param index */
+ int off, /* mem. offset */
+ void *fruit1, /* 1st data arg */
+ void *fruit2); /* 2nd data arg */
+\end{lstlisting}
+
+\begin{lstlisting}
+const struct lemona_mixer lemona_mixers[]= {
+ /* ... */
+ {
+ .sysnr = __NR_open,
+ .in = {
+ .argnr = 3,
+ .extnr = 0,
+ .handlers = {
+ { .dual = false , .blade = lemona_blade_string_null },
+ { .dual = false , .blade = lemona_blade_integer },
+ { .dual = false , .blade = lemona_blade_integer },
+ }
+ },
+ .out = {
+ .argnr = 1,
+ .extnr = 1,
+ .handlers = {
+ { .dual = false , .blade = lemona_blade_integer },
+ { .dual = false , .blade = lemona_blade_string_fd },
+ },
+ }
+ },
+ /* ... */
+};
+\end{lstlisting}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Controls
+
+\section{Controls}
+
+\begin{verbatim}
+$> cd $(PATH_TO_KERNEL_SRC)
+$> wget http://lemona.googlecode.com/svn/trunk/patchs/patch-2.6.26.3
+$> patch -p1 < patch-2.6.26.3
+$> make menuconfig
+$> make && makes modules_install && make install
+\end{verbatim}
+
+
+\begin{verbatim}
+$> cd $(PATH_TO_MODULES)
+$> sudo insmod ./lemona.ko
+$> dmesg | tail -2
+ -==Lemona==- Initialization for kernel tree 2.6.26.3...
+ -==Lemona==- Done.
+$> sudo rmmod lemona
+$> dmesg | tail -2
+ -==Lemona==- Uninitializing...
+ -==Lemona==- Done.
+\end{verbatim}
+
+
+% TODO

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.bib
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.bib
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,350 @@
+@article{
+aranya:TRACEFS,
+ Author = {Aranya, A. and Wright, C. P. and Zadok, E.},
+ Title = {Tracefs: A File System to Trace Them All},
+ Year = {2004} }
+
+
+
+@article{
+balon:CIF,
+ Author = {Balon, N. and Stovall, R. and Scaria, T.},
+ Title = {Computer Intrusion Forensics Research Paper},
+ Year = {} }
+
+
+
+@article{
+bauer:SYSLOG,
+ Author = {Bauer, M.},
+ Title = {Paranoid Penguin: syslog Configuration},
+ Journal = {Linux Journal},
+ Volume = {2001},
+ Number = {92},
+ Year = {2001} }
+
+
+
+@article{
+cantrill:DIPS,
+ Author = {Cantrill, B. M. and Shapiro, M. W. and Leventhal, A. H.},
+ Title = {Dynamic instrumentation of production systems},
+ Year = {2004} }
+
+
+
+@article{
+cornell:WAYBACK,
+ Author = {Cornell, B. and Dinda, P. A. and Bustamante, F. E.},
+ Title = {Wayback: A User-level Versioning File System for Linux},
+ Journal = {Proceedings of Usenix Annual Technical Conference, FREENIX
Track},
+ Pages = {19–28},
+ Year = {2004} }
+
+
+
+@article{
+desnoyers:LTTNG,
+ Author = {Desnoyers, M. and Dagenais, M. R.},
+ Title = {The lttng tracer: A low impact performance and behavior
monitor for GNU/Linux},
+ Journal = {OLS (Ottawa Linux Symposium)},
+ Pages = {209–224},
+ Year = {2006} }
+
+
+
+@article{
+dunlap:REVIRT,
+ Author = {Dunlap, G. W. and King, S. T. and Cinar, S. and Basrai, M. A.
and Chen, P. M.},
+ Title = {ReVirt: enabling intrusion analysis through virtual-machine
logging and replay},
+ Journal = {ACM SIGOPS Operating Systems Review},
+ Volume = {36},
+ Pages = {211-224},
+ Year = {2002} }
+
+
+
+@misc{
+eigler:SYSTEMTAP,
+ Author = {Eigler, F. C. and Prasad, V. and Cohen, W. and Nguyen, H. and
Hunt, M. and Keniston, J. and Chen, B.},
+ Title = {Architecture of systemtap: a Linux trace/probe tool},
+ URL = {http://sourceware.org/systemtap/archpaper.pdf},
+ Year = {2005} }
+
+
+
+@article{
+garfinkel:TRAPS,
+ Author = {Garfinkel, T.},
+ Title = {Traps and Pitfalls: Practical Problems in System Call
Interposition Based Security Tools},
+ Journal = {Proceedings of the Network and Distributed Systems Security
Symposium},
+ Year = {2003} }
+
+
+
+@article{
+goel:FORENSIX,
+ Author = {Goel, A. and Feng, W. C. and Maier, D. and Walpole, J.},
+ Title = {Forensix: a robust, high-performance reconstruction system},
+ Journal = {Distributed Computing Systems Workshops, 2005. 25th IEEE
International Conference on},
+ Pages = {155-162},
+ Year = {2005} }
+
+
+
+@article{
+hiramatus:DJPROBE,
+ Author = {Hiramatsu, M. and Oshima, S.},
+ Title = {Djprobe—Kernel probing with the smallest overhead},
+ Journal = {Linux Symposium},
+ Year = {2007} }
+
+
+
+@article{
+keniston:PTRACE,
+ Author = {Keniston, J. and Mavinakayanahalli, A. and Panchamukhi, P.
and Prasad, V.},
+ Title = {Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User
Apps},
+ Journal = {Linux Symposium},
+ Year = {2007} }
+
+
+
+@article{
+king:BACKTRACKING,
+ Author = {King, S. T. and Chen, P. M.},
+ Title = {Backtracking intrusions},
+ Journal = {ACM Transactions on Computer Systems (TOCS)},
+ Volume = {23},
+ Number = {1},
+ Pages = {51-76},
+ Year = {2003} }
+
+
+
+@article{
+knight:VULNERABILITIES,
+ Author = {Knight, E.},
+ Title = {Computer Vulnerabilities},
+ Year = {2000} }
+
+
+
+@article{
+krishnakumar:KPROBE,
+ Author = {Krishnakumar, R.},
+ Title = {Kernel korner: kprobes-a kernel debugger},
+ Journal = {Linux Journal},
+ Volume = {2005},
+ Number = {133},
+ Year = {2005} }
+
+
+
+@misc{
+sun:VIRTUALBOX,
+ Author = {Microsystems, S.},
+ Title = {VirtualBox},
+ URL = {http://www.virtualbox.org},
+ Year = {} }
+
+
+
+@article{
+pohlack:RTSMON,
+ Author = {Pohlack, M. and Dobel, B. and Lackorzynski, A.},
+ Title = {Towards Runtime Monitoring in Real-Time Systems},
+ Journal = {Proceedings of the Eighth Real-Time Linux Workshop},
+ Year = {2006} }
+
+
+
+@article{
+rekhis:TADISI,
+ Author = {Rekhis, S.},
+ Title = {Theoretical Aspects of Digital Investigation of Security
Incidents},
+ Year = {} }
+
+
+
+@article{
+rogers:FORENSICS,
+ Author = {Rogers, M.},
+ Title = {COMPUTER FORENSICS: EVIDENCE HANDLING & MANAGEMENT},
+ Year = {} }
+
+
+
+@article{
+salvador:IDS,
+ Author = {Salvador, J. A. F.},
+ Title = {An intrusion detection system based in the gathering of Linux
Syslog Logs from Linux, Windows NT and Snort},
+ Year = {2003} }
+
+
+
+@article{
+sarmoria:MMF,
+ Author = {Sarmoria, C. G. and Chapin, S. J.},
+ Title = {Monitoring access to shared memory-mapped files},
+ Journal = {Proc. of the 2005 Digital Forensics Research Workshop
(DFRWS). New Orleans},
+ Year = {2005} }
+
+
+
+@article{
+spitzner:KYE,
+ Author = {Spitzner, L.},
+ Title = {Know Your Enemy: A Forensic Analysis},
+ Journal = {URL:
http://www.securityfocus.com/focus/ih/articles/foranalysis.html},
+ Year = {2000} }
+
+
+
+@article{
+stallings:NETCRYPTO,
+ Author = {Stallings, W.},
+ Title = {Cryptography and Network Security},
+ Year = {2003} }
+
+
+
+@article{
+tan:READINESS,
+ Author = {Tan, J.},
+ Title = {Forensic Readiness},
+ Journal = {The CanSecWest Computer Security Conference, April},
+ Year = {2001} }
+
+
+
+@article{
+wisniewski:MULTIPROC,
+ Author = {Wisniewski, R. W. and Rosenburg, B.},
+ Title = {Efficient, Unified, and Scalable Performance Monitoring for
Multiprocessor Operating Systems},
+ Journal = {Supercomputing, 2003 ACM/IEEE Conference},
+ Pages = {3-3},
+ Year = {2003} }
+
+
+
+@article{
+zanussi:RELAYFS,
+ Author = {Zanussi, T. and Yaghmour, K. and Wisniewski, R. and Moore, R.
and Dagenais, M.},
+ Title = {relayfs: An Efficient Unified Approach for Transmitting Data
from Kernel to User Space},
+ Journal = {Linux Symposium},
+ Year = {2003} }
+
+
+
+@article{
+mohan:REPOFS,
+ Author = {Mohan, P. and Aanjhan, R.},
+ Title = {Mounting of Version Control Repositories: RepoFS},
+ Journal = {High Performance Computing-HiPC 2006},
+ Year = {2006} }
+
+
+
+@article{
+letscher:CARBON,
+ Author = {Letscher, D.},
+ Title = {Carbon Copy Filesystem: A Real Time Snapshot Filesystem Layer},
+ Year = {2006} }
+
+
+
+@misc{
+sun:ZFS,
+ Author = {Microsystems, S.},
+ Title = {ZFS: The last word in file systems},
+ Year = {} }
+
+
+
+@misc{
+vmware,
+ Author = {VMWare, Inc.},
+ Title = {VM Ware},
+ URL = {http://www.vmware.com},
+ Year = {} }
+
+
+
+@misc{
+symantec:GHOST,
+ Author = {Sysmantec, Corp.},
+ Title = {Norton Ghost},
+ URL = {http://www.symantec.com/norton/ghost},
+ Year = {} }
+
+
+
+@misc{
+cederqvist:CVS,
+ Author = {Cederqvist, P.},
+ Title = {Version Management with CVS},
+ Publisher = {Network Theory Ltd.},
+ Year = {2002} }
+
+
+
+@book{
+collins-sussman:SVN,
+ Author = {Collins-Sussman, B. and Fitzpatrick, B. W. and Pilato, C. M.},
+ Title = {Version Control with Subversion},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2004} }
+
+
+
+@article{
+BAZAAR,
+ Title = {Bazaar Distributed VCS},
+ Year = {} }
+
+
+
+@misc{
+GIT,
+ Title = {Git},
+ URL = {http://git.or.cz/},
+ Year = {} }
+
+
+
+@misc{
+osullivan:MERCURIAL,
+ Author = {O’Sullivan, B.},
+ Title = {Distributed revision control with Mercurial},
+ Year = {2006} }
+
+
+
+@book{
+love:LINUXSYSPROG,
+ Author = {Love, Robert},
+ Title = {Linux System Programming: Talking Directly to the Kernel and C
Library},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2007} }
+
+
+
+@book{
+bovet:ULK,
+ Author = {Bovet, D. P. and Cesati, M.},
+ Title = {Understanding the Linux Kernel},
+ Publisher = {O'Reilly Media, Inc.},
+ Year = {2005} }
+
+
+
+@book{
+mitnick:DECEPTION,
+ Author = {Mitnick, K. D. and Simon, W. L.},
+ Title = {The Art of Deception: Controlling the Human Element of
Security},
+ Publisher = {Wiley},
+ Year = {2002} }
+
+
+

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-references.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,6 @@
+\newpage
+\pagestyle{plain}
+\addcontentsline{toc}{chapter}{References}
+\bibliographystyle{elsart-harv-ms}
+\bibliography{lemona-thesis-references}
+\newpage

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-related-work.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-related-work.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,503 @@
+\chapter{Related Work}
+
+There is an urging need for always more dynamic and autonomous
+intrusion detection systems and forensics analysis tools, capable of
+reacting in \emph{real-time} to attempted break-ins by securing the system
or
+recording suspicious activity.
+
+Therefore, there is a flourishing mass of research projects published
+on the net, describing various approaches to the resolution of
+problems we exposed earlier, and which aim to fill in the gaps left
+open by the current security architectures already available on
+standard operating systems.
+
+We will attempt to review these approaches from a conceptual
+standpoint and provide an extensive review of their capabilities and
+efficiency, to determine how they qualify (or not) for \textbf{Lemona}.
+
+Though forensics analysis and system surveillance encompass numerous
+fields, like we outlined above, we are only going to focus on the
+elements for which we intend to conduct (at least in the first place)
+thorough research leading to the design and implementation
\textbf{Lemona}'s
+framework. Therefore, we will describe below research projects and
+their approaches following four axis of study. Namely:
+
+\begin{itemize}
+ \item Monitoring Specifics
+ \item Reporting Specifics
+ \item Forensics Analysis Specifics
+ \item Recovery / Reconstruction Specifics
+\end{itemize}
+
+\section{Monitoring Specifics}
+
+Monitoring is the act of gathering information about a target system
+and its current active state(s). There are various ways, which one can
+use to monitor a system. We are going to review them below.
+
+\subsection{Logging}
+
+We refer as logging to the basic activity or recording a piece of
+software's activity via the duplication and storage of its obvious
+Input/Output channels and actions. Such a monitoring system is a
+common and well-known feature, available on almost every mainstream
+system nowadays.
+
+Its full range of capabilities can be quite large, as it embodies the
+simple act of an application logging its own I/O and actions to buffer
+files, either voluntarily (via the use of standard log files), or
+indirectly (via the use of standard capture frameworks, such as the
+classic syslog protocol and its \emph{syslogd} daemon on \emph{UNIX}
+systems \cite{bauer:SYSLOG}). The gathering and centralization of
+different logging information can in some cases lead to the
+realization of an \emph{IDS} \cite{salvador:IDS}.
+
+Logging features do not present much of an interest for us in the
+context of our research, as they are by all aspects an existing and
+well-defined solution to higher-level concerns, but which cannot be
+used to record a system's lifelong activity in a consistent, usable
+and exhaustive manner.
+
+They are, however, a standard and usable complement to other
+solutions, and can be used as complimentary evidence. They sometimes
+are enough to find the beginning of an intrusion scheme as shown by
+\textbf{Spitzner} for his \textbf{HoneyPot Project} \cite{spitzner:KYE}.
+
+\subsection{System Call Interception}
+
+A very popular monitoring technique, which is still being heavily
+researched is the one referred to as ``\emph{System Call Interposition}''
or
+``\emph{System Call Interception}''.
+
+This technique relies on the fact that during the lifetime of any
+given process or system activity of any kind, the \emph{kernel}'s core
system
+functions (the "\emph{system calls}"), will be called upon to execute
+specific actions.
+
+It is possible to "intercept" at runtime calls to these core
+functions. This is a very common method, used for instance by debugger
+and tracers. It can be achieved in various ways; however, the level of
+granularity and reliability varies.
+
+One could for instance use standard tools implementing the POSIX
+tracing interfaces, such as the \emph{strace} binary and its
+underlying `ptrace()` function \cite{keniston:PTRACE}. `ptrace()`
+allows a program to spawn a new process and follow its execution from
+start to finish, allowing the observer to monitor each call of the
+child process to the system's function, and to retrieve memory
+states. Similarly, one can attach to an existing `ptrace()` to undergo
+the same examination.
+
+However, `ptrace()` is not a reliable and viable solution in the case of
+highly-critical systems, and for strict forensics examinations.
+
+First of all `ptrace()` executes in userland and may be tampered with
+relatively easily, allowing one to circumvent its action. Following a
+similar approach, an attacker could also use `ptrace()` to its own
+advantage to de-route a tracing system using `ptrace()` by using
\emph{strace}
+himself, thus tracing the tracer and redefining its behavior at
+runtime.
+
+Finally, `ptrace()`'s performance might not be satisfactory. This not
+only comes from the fact that a program executing `ptrace()` would
+reside in userland, thus being undermined by resource-consuming
+context switches, but also that it would not have a granularity
+accurate enough to record timestamped valid system traces.
+
+The other solution, which is employed by several projects
+\cite{goel:FORENSIX,king:BACKTRACKING,wisniewski:MULTIPROC}, is to
+patch the \emph{kernel} source or to design it with the tracing in
+mind from the beginning (the difference being mostly on the
+architecture and goals chosen as well on the post-processing
+tools). However, one need to be careful about the different problems
+inherent to this style of instrumentation as referenced in the "Traps
+and Pitfalls" publication by Garfinkel \cite{garfinkel:TRAPS}.
+
+\subsection{Hooks and Checkpoints}
+
+We call a "hook" or a "checkpoint" a deliberate modification to a
+system's \emph{kernel} meant to inject a static piece of software to record
+activity occurring at this specific point of the \emph{kernel}'s execution
+flow.
+
+This approach can be used for various purposes, for instance to
+examine the performance of a system (by defining checkpoints one could
+re-use to benchmark it) or to realize system call interposition (which
+we have treated as a special case earlier).
+
+This method provide the advantage of being quite flexible when it
+comes to its penetration capabilities: it is virtually possible to
+define static hooks for any part of software, as long as one can edit
+this software and recompile it for future - traced - execution. LTTng
+chose this approach while managing to incur a low performance impact
+when the checkpoints are not enabled \cite{desnoyers:LTTNG}.
+
+This technique is also used by projects, which goals are to only
+monitor a subset of the \emph{kernel} operations. Sarmoria
+\cite{sarmoria:MMF} used it to update the Linux Kernel Memory
+Management code in order to instrument accesses realized on
+Memory-Mapped files.
+
+The obvious trade-off, however is the complexity of such a
+manipulation, as it implies the tampering of software components of
+the \emph{kernel}. Such a system has to be validated against any new
+update of the \emph{kernel} source tree to ensure that new code
+changes do not influence its behavior and/or stability. On the other
+hand, Sun with its Solaris OS doe not incur this penalty since the
+\textbf{DTrace} patches are maintained and integrated by the \emph{kernel}
+developers themselves \cite{cantrill:DIPS}.
+
+In addition, static hooks are paradoxically inflexible, as you cannot
+redefine at a user's request and at any given time the behavior of a
+given checkpoint.
+
+\subsection{Software Probes}
+
+Software \emph{probes} are in the logical continuity of static system
+\emph{hooks}. We call a software \emph{probe} any piece of software that
allows
+the injection at a given point of a software (the \emph{hook}) another
+independent piece of software (the \emph{probe}), which will commonly be
+used for monitoring purposes.
+
+We call \emph{kernel probes} instances of such a system that are
implemented
+in kernel land and allow an observer to monitor the \emph{kernel}'s
activity.
+
+Their underlying logic is the same as the one of a system hook, except
+they allow one to reconfigure (relatively) dynamically new probes with
+different behaviors, and to hook itself up at any point of the
+execution flow, granted one knows to which address to jump.
+
+A \emph{probe} will simply stop the execution of a process to execute as a
+"side behavior" when a checkpoint or hook is reached, and call its
+defined handler(s). Upon completion of the \emph{probe}'s task(s), the
+\emph{probe} redirects the execution flow to the exact point where it left
+off.
+
+Various systems have been experimented with, benchmarking different
+scenarios to reach decent level of granularity and verbosity for
+low-level tracing, with very little overhead. On Linux, the most
+common ones are \textbf{Kprobe} \cite{krishnakumar:KPROBE} and
\textbf{Djprobe}
+\cite{hiramatus:DJPROBE}; the difference between the two being their
+implementations. The approach which has been chosen by Djprobe allow
+for less performance impact although in some case Kprobe mechanism
+will need to be used as a fall-back.
+
+These probing facilities has lead to some interesting projects like
+the \textbf{Systemtap} architecture \cite{eigler:SYSTEMTAP} which based on
+these probes allow a more generic approach for generating probing
+points or like \textbf{Uprobes} \cite{keniston:PTRACE} which duplicate the
+behavior of \textbf{Kprobes} for userland application.
+
+\section{Information Reporting Specifics}
+
+Reporting is the act of transferring information from the source
+system (also referred to as the audited system), where we gather
+information from, to the storage system (also referred to as the watch
+system), where we store the relevant collected data and process it to
+extract information.
+
+Reporting can be done in various ways, and even though it isn't in
+itself a specific research point we are focusing on, it poses some
+interesting security issues and design constraints, which impact its
+use and the functionalities of the complete surveillance system.
+
+\subsection{Reporting Architecture}
+
+We distinguish three different approaches to the design of the reporting
+architecture.
+
+\subsubsection{Local}
+
+Some systems use a simple local reporting and storage system. This
+system is the simplest by design, and requires no additional hardware
+and diminishes the overhead of having to manage separate systems.
+
+However, it can also be rendered completely pointless if an attacker
+gets full control of the compromised system and tampers with the
+recorded data after they have been collected. Similarly, if the system
+is brought to a complete failure, it might not be possible to recover
+the collected data, thus rendering the whole surveillance system
+ineffective.
+
+Linux Kernel modules for instance, can use the relayfs
+\cite{zanussi:RELAYFS} facility to do so, making their logs more
+easily accessible by userland software thus avoiding to bloat the logs
+captured by \emph{syslogd}.
+
+\subsubsection{Remote and Centralized}
+
+This problem can be addressed by the use of a remote storage
+system. The reporting agents located on the source host transmit all
+the required data over a (preferably secure) communication
+channel. This is the architecture chosen by \textbf{Forensix}
+\cite{goel:FORENSIX}.
+
+As the collected data is being sent over the network to a separate
+host, we can assign another team to the surveillance task, thus
+separating concerns and restricting accesses. In the case of a
+complete failure of the monitored system, the data can still be
+accessed and the forensics analysis undergone post-mortem.
+
+However, a remote architecture, as opposed to a local one, also poses
+several security issues. An attacker might be able to interfere with
+such a system by:
+
+\begin{itemize}
+ \item Intercepting the collected data to get some knowledge on the
surveillance system
+ \item Penetrating and compromising the remote storage point itself
+ \item Severing the connection between the remote storage point and the
monitored host before attempting to break into the later.
+\end{itemize}
+
+\subsubsection{Remote, Decentralized and Redundant}
+
+A possible alternative to the previous solution is to use a
+decentralized and/or redundant architecture.
+
+By "decentralized", we mean an architecture where only partial
+information about the monitored host is being stored on a single
+storage point. Reconstructing the data could only be done by
+retrieving it from various storage points, thus adding another layer
+of anonymity (and possibly reducing load and separating concerns
+again, by allocating one storage point to network data, and another
+one to local IO, for instance).
+
+By "redundant", we mean an architecture where the data is being
+duplicated on various hosts, ensuring that it can be cross-checked for
+future use. Thus, the risk of loss of information by accidental loss
+or malevolent tampering is reduced, as the complexity increases for
+the attacker to convey his tracks.
+
+However, we have not found any reference to any project using such a
+design to this day.
+
+\subsection{Reporting Modes}
+
+We expose here two different concepts in the use of reporting techniques.
+
+\subsubsection{Uni-Directional}
+
+We call "uni-directional" reporting the act of only reporting
+information from one host to another. In such a situation, we are only
+in presence of a monitored source host, and a storage target host.
+
+Though the information can be processed either in \emph{near real-time}
+or after a given delay, in this concept the surveillance system will
+not provide feedback to the monitored source to report on recommended
+preventive or mitigating actions and counter-measures, should an
+attack attempt be detected.
+
+\subsubsection{Bi-Directional}
+
+We call "bi-directional" a setting where both the monitored source and
+the storage target communicate and interact with one another.
+
+In this setting, the surveillance system makes it possible for the
+host to react to an attack attempt or a system failure by receiving
+information from the storage point, which takes care of the defensive
+decision-taking process.
+
+Such a design allows for dynamic defenses, and opens a very broad
+range of perspective for surveillance systems, and aims to defer the
+use of forensics analysis to a last resort.
+
+Furthermore, a monitored system might be instructed to disconnect of
+the network or shut down if an aggression is being detected and cannot
+be stopped, to prevent theft of sensitive information.
+
+However, because of their complexity, it is difficult to implement
+this kind of surveillance system in a practical setting, considering
+the actual state of the hardware components, in terms of processing
+power and bandwidth.
+
+\subsection{Response Times}
+
+The response time of a surveillance system - be it an \emph{IPS},
\emph{IDS}, a
+hybrid system or a \emph{honeypot} - can be sorted in one of the following
+categories.
+
+\subsubsection{Delayed / Post-Mortem}
+
+A "\emph{delayed}" or "\emph{post-mortem}" analysis is performed after the
event
+occurred. Either the delay is so important that any relevant action
+cannot be undertaken to have any noticeable effect, or the system is
+already considered compromised, and eventually damaged beyond repair.
+
+We consider it a "\emph{delayed}" response time if we are in presence of a
+slow, but still reactive surveillance system (either automated or
+controlled by a human).
+
+We consider it a "\emph{post-mortem}" response time if no attempt is being
+made to process the information at runtime, and the data is only being
+inspected to undertake a forensic examination after an incident.
+
+\subsubsection{Near Real-Time}
+
+A "\emph{near real-time}" response time is considered when a monitoring
+system is capable of reacting to an attempted attack in a very short
+delay, possibly while the attack is being performed.
+
+There is however still a delay, as the surveillance system only
+collects and records data after an activity occurs, thus making it
+impossible to guarantee (though it remains possible) the termination
+an attack before it reaches a critical state.
+
+\subsubsection{Real-Time}
+
+A "\emph{real-time}" surveillance system is one that can actually process
and
+react to the collected information before any further action can be
+undertaken (either by the attacker or the monitored
+system).
+
+Typically, this would be possible by using a bi-directional reporting
+system if we were in a setting allowing a monitored system to trace
+and intercept all user activity, report it to the watch system, which
+would then validate the pending action based on its knowledge of the
+actual state of the monitored system. It would then provide it with
+informative feed-back to block the required action (and possibly
+contain or expel the attacker) or allow it to executed.
+
+This approach, as idealist as it may appear, is theoretically
+possible. It is the logical evolution and combination of our hybrid
+defense systems and \emph{honeypots}, combining reactive monitoring and
+control for dynamic intrusion prevention, detection, containment and
+mitigation. Unfortunately, considering the current state of hardware
+components at the day of this writing, the impact on the monitored
+system's performance would probably render it unusable for most
+enterprise use cases, and we assume this is the only reason why such a
+system has not been designed and implemented yet.
+
+\section{Forensics Analysis Specifics}
+
+We call here forensics analysis the act of processing collected data
+to examine a digital crime-scene, for instance by reproducing an
+attempted attack (or any other critical or casual activity).
+
+This is made possible through extensive tracing of all low-level user
+activity as described in the previous sections, which allows the
+development of forensics tools to go through a legitimate or
+illegitimate user step-by-step.
+
+Eventually, such an approach allows one to not only reproduce an
+attack, but also to:
+
+\begin{itemize}
+ \item understand how the system has been penetrated and compromised,
+ \item recover a damaged or destroyed system.
+\end{itemize}
+
+There are various appropriate techniques we list as reference on how
+to reproduce an attack. Some approaches rely on the very fine
+granularity of the monitored data and its timestamping to build a
+textual and possibly visual representation of the penetration.
+
+An example of textual representation would consist in the querying of
+the collected database to extract only information relative to a given
+time frame, for a given user's execution of a very specific command.
+
+An example of a visual representation could be derived from such
+queries to form a graphical workflow of every \emph{atomic} actions leading
+ultimately to the compromised state, from the evidence of the attacker
+exploiting a vulnerability to his covering of his tracks.
+
+\section{Reconstruction and Recovery Specifics}
+
+We provide in this section a brief overview of the existing data
+recovery methods, as well as the existing system and scenario
+reconstruction techniques used by commercial and open source software
+solutions.
+
+We outline their specific strengths and weaknesses, to lead to the
+conclusion that they could be combined for improved performance
+depending on the favored angle of the size/speed/integrity trade-off.
+
+\subsection{Imaging: Snapshots, Clones and Ghosts}
+
+In the world of software backup, an image refers to a bit-to-bit copy,
+which can be saved on storage units. In the occurrence of a system
+crash, the whole image of the damaged system can be copied back onto
+the live hardware (or on another machine with similar hardware
+specifications). This technique can be found in various commercial and
+open source software solutions.
+
+The term snapshot is often used in virtualized environments, like in
+the xVM VirtualBox \cite{sun:VIRTUALBOX} or VMWare \cite{vmware}
+products. In this case, a snapshot of the virtual machine is captured
+to be reverted to at a later stage. Various file systems, like ZFS
+\cite{sun:ZFS}, also use the same systems to revert to previous
+states.
+
+The term clone is more general, and usually used in the context of
+disk cloning, when a bit-to-bit copy of single hard drive produced. It
+is also sometimes referred to as ghosting, as a drive is being
+completely cloned, hence being frozen as a shadow copy. This term is
+used for instance by Symantec's Norton Ghost \cite{symantec:GHOST}
+product line.
+
+Imaging solutions provide a relatively convenient method for
+safeguarding the loss of sensitive data. However, they also come with
+some major drawbacks, as they might require quite a huge amount of
+storage space, and a reliable infrastructure to automate the
+snapshots. The principle of "incremental backup" comes in very handy
+here, as the successive storage of regular snapshots allows one to
+remove previous images.
+
+In addition to this, if a snapshot is taken after the state of a
+machine has been (even partially) compromised, and the previous
+backups have not been preserved, then we are left with a potentially
+harmful snapshot.
+
+\subsection{Revisions and Rollbacks}
+
+Revision Control Systems provide incremental backup features to
+document management systems or file systems, while allowing them to
+spare some storage space. Such solutions allow the user to roll back
+to a previous state, as one would do with an image, but by using
+incremental differential revisions of a file. In this case, a given
+file is not being backed up following at regular time intervals, but
+every time a modification occurs. Of course, it means this setting
+will potentially affect the required storage space on very active
+systems.
+
+Such systems exist for various purposes, and are very common as
+Software Configuration Management suites or Version Control
+System. Classics of the likes are of course CVS \cite{cederqvist:CVS},
+SubVersioN \cite{collins-sussman:SVN}, Bazaar \cite{BAZAAR}, Mercurial
+\cite{osullivan:MERCURIAL}, git \cite{GIT}... each and every one of
+them coming with similar capabilities extended by sets of more
+specific features, depending on the desired software development
+approach (distributed or centralized, for instance).
+
+Some experimental file systems also resort to revision control, like
+Wayback \cite{cornell:WAYBACK}, RepoFS \cite{mohan:REPOFS} or the
+Carbon Copy FileSystem \cite{letscher:CARBON}.
+
+\subsection{Virtualization / Sandboxing}
+
+Virtualization is a technique allowing a complete system to run on top
+of another system without being aware of it. This has become quite
+common in the past couple of years, rendering hardware abstraction
+transparent, and allowing graceful degradation of damaged systems.
+
+ReVirt \cite{dunlap:REVIRT} had proven that it is possible, by
+capturing and logging all non-deterministic events generated by a
+target system running inside a virtual machine, to be able to
+reproduce actively the execution of a system from a given
+checkpoint. However, this technique has the disadvantage to take as
+much time to reconstruct and discover what happened as the time it
+took to the intrusion to be realized.
+
+\subsection{Reconstruction}
+
+We have found two different but interesting methods for reconstructing
+a path of event.
+
+The first one is the approach taken by \textbf{Forensix}
\cite{goel:FORENSIX}
+which can generate SQL-based queries to retrieve a succession of
+events depending on different key input (PID, Timefame, paths, ...).
+
+The second approach, which Bactracker \cite{king:BACKTRACKING}
+implements, starts from the intrusion detection point and then goes
+backwards, building a graph of all possible chains of events, which
+could have led to the intrusion. This allows the identification of the
+process used by the intruder to achieve his mischief.
+

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-abstract.tex
==============================================================================
--- (empty file)
+++
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-abstract.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,7 @@
+\abstract{Computer forensics tools provide capabilities to identify
+ the circumstances, causes and effects of criminal activities or
+ accidental damage to computer systems. We present in this thesis a
+ brief overview of the general problems of computer forensics as well
+ as the existing research in this field. We then introduce Lemona,
+ our proposal for a forensics architecture relying on open standards
+ and implementing fine-grained monitoring facilities.}

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknowledgments.tex
==============================================================================
--- (empty file)
+++
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknowledgments.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,44 @@
+\chapter*{Acknowledgments}
+\addcontentsline{toc}{chapter}{Acknowledgments}
+
+\paragraph{}
+We would like to thank a number of people for their collaboration
+and support throughout the conduct of this project and the realisation
+of our thesis.
+
+\paragraph{}
+First of all, we would like to thank professor \textbf{Mickael Camus},
+researcher in artificial intelligence and artificial
+consciousness. Mickael was formerly one of our teachers at the
+\emph{\{EPITECH.\} European Institute of Technology} and former
+laboratory development manager at the \emph{L.\{E.\}.R.I.A.}, for the
+quality-teaching he provided us with, and for accepting to be our
+supervisor for this project. We especially thank him for his
+managerial support and the directions he gave us to interact in an
+academic environment.
+
+Secondly, professor \textbf{Milton Baar}, expert in computer security
+and IT security management, and lecturer at the \emph{Macquarie
+ University}. Milton was kind enough to assert the validity of our
+research and provide us with timely feedback.
+
+Finally, professor \textbf{Manolya Kavakli}, researcher in virtual and
+augmented reality, lecturer at \emph{Macquarie University}, and
+director of the Master of Information Technolgy program.
+
+\paragraph{}
+We also thank professor \textbf{Peter Busch}, director of postgraduate
+programs of the \emph{Department of Computing} at \emph{Macquarie
+ University}. His availability and understanding made it possible for
+us to study in the best conditions, with regards for our previous
+academic records.
+
+Thanks also go out to the staff of \emph{Macquarie International} for
+their support and their dedication to manage, support and counsel an
+the massive international student community.
+
+\paragraph{}
+And of course, we thank all the people whose steps we have been
+working in while developing and experimenting with Lemona, and who
+have provided valuable input to the fields of computer security and
+forensics.

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknownledgments.tex
==============================================================================
--- (empty file)
+++
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-acknownledgments.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1 @@
+

Added:
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-summary.tex
==============================================================================
--- (empty file)
+++
docs/publications/thesis/msc-thesis-2008/lemona-thesis-title-summary.tex
Sat Nov 15 22:13:14 2008
@@ -0,0 +1,19 @@
+\chapter*{Summary}
+\addcontentsline{toc}{chapter}{Summary}
+
+When incidents occur within or when attackers penetrate into
+information systems, preventive actions are no longer an appropriate
+resort to turn to. It is then vital for the targeted organizations to
+review and understand the what's, why's and how's of the threats, as
+well as their executions and their outcomes.
+
+This is usually the role of a team of computer forensics experts,
+which will go through the tedious task of investigating the digital
+crime scene. Because of the very nature of the crime, investigators
+need to collect non-disputable evidence to build a valid case.
+
+However, it is not always possible to conduct such an investigation on
+the target machine, as it may have been physically destroyed or have
+its memory units wiped out clean by skillful malevolent attackers. To
+address this problem, we turn ourselves towards post-mortem forensics
+analysis tools.

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis-title.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis-title.tex Sat
Nov 15 22:13:14 2008
@@ -0,0 +1,36 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% title parts (title, preface, summary, acknowledgments ...)
+
+\begin{titlepage}
+ \title{Lemona: Towards an Open Architecture for Decentralized Forensics
Analysis}
+ \author{Kenfe-Mickael Laventure \and Laurent Malvert}
+ \date{November 17, 2008}
+ \maketitle
+ \input{lemona-thesis-title-abstract}
+\end{titlepage}
+
+
+\input{lemona-thesis-title-summary}
+\input{lemona-thesis-title-acknowledgments}
+
+%\begin{keywords}
+%computer, forensics, investigation, kernel, linux, system calls,
+%interception, monitoring, lemona, architecture
+%\end{keywords}
+
+\markboth{Thesis}{Laventure \MakeLowercase{\textit{et}} Malvert: Lemona}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Tables of Contents / Tables / Figures
+
+% Remove parskip for toc
+\setlength{\parskip}{0ex plus 0.5ex minus 0.2ex}
+\tableofcontents
+\newpage
+\listoftables
+\newpage
+\listoffigures
+
+% Dutch style of paragraph formatting, i.e. no indents.
+\setlength{\parskip}{1.3ex plus 0.2ex minus 0.2ex}

Added: docs/publications/thesis/msc-thesis-2008/lemona-thesis.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/lemona-thesis.tex Sat Nov 15
22:13:14 2008
@@ -0,0 +1,55 @@
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Document Configuration Header
+\input{template-thesis}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Document Start
+\begin{document}
+
+\frontmatter
+
+\input{lemona-thesis-title}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Chapters
+
+\mainmatter
+
+% Adjustments headers
+\fancyhead[LO]{\leftmark}
+\fancyhead[RE]{\emph{Chapter \thechapter}}
+
+\input{lemona-thesis-introduction}
+\input{lemona-thesis-related-work}
+\input{lemona-thesis-methodology}
+\input{lemona-thesis-experimentation}
+\input{lemona-thesis-discussion}
+\input{lemona-thesis-conclusion}
+
+
+\nocite{*}
+
+\backmatter
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% References
+
+\input{lemona-thesis-references}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Bibliography
+
+\input{lemona-thesis-bibliography}
+
+
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+% Appendices
+
+\input{lemona-thesis-appendices}
+
+
+\end{document}

Added: docs/publications/thesis/msc-thesis-2008/template-ieee.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/template-ieee.tex Sat Nov 15
22:13:14 2008
@@ -0,0 +1,18 @@
+\documentclass[twocolumn,english, journal]{IEEEtran}
+\usepackage[T1]{fontenc}
+\usepackage{verbatim}
+\usepackage{graphicx}
+
+\makeatletter
+
+\providecommand{\tabularnewline}{\\}
+
+\let\oldforeign@language\foreign@language
+\DeclareRobustCommand{\foreign@language}[1]{%
+ \lowercase{\oldforeign@language{#1}}}
+\newtheorem{thm}{Theorem}
+\newtheorem{lemma}{Lemma}
+
+\usepackage{babel}
+
+\makeatother

Added: docs/publications/thesis/msc-thesis-2008/template-thesis.tex
==============================================================================
--- (empty file)
+++ docs/publications/thesis/msc-thesis-2008/template-thesis.tex Sat Nov 15
22:13:14 2008
@@ -0,0 +1,44 @@
+\documentclass[a4paper,fleqn]{book}
+
+\usepackage{graphicx,amsfonts,psfrag,fancyhdr,layout,appendix,subfigure}
+\usepackage[sectionbib]{natbib}
+\usepackage{chapterbib}
+\usepackage{listings}
+
+% Set equal margins on book style
+\setlength{\oddsidemargin}{33pt} % was: 53pt
+\setlength{\evensidemargin}{33pt} % was: 53pt
+\setlength{\marginparwidth}{42pt} % was: 57pt
+\setlength{\footskip}{15pt} % was: 30pt
+
+% Redefine plain page style
+\fancypagestyle{plain}{
+ \fancyhf{}
+ \renewcommand{\headrulewidth}{0pt}
+ \fancyfoot[LE,RO]{\thepage}
+}
+
+% Code for creating empty pages
+% No headers on empty pages before new chapter
+\makeatletter
+\def\cleardoublepage{\clearpage\if@twoside \ifodd\c@page\else
+ \hbox{}
+ \thispagestyle{plain}
+ \newpage
+ \if@twocolumn\hbox{}\newpage\fi\fi\fi}
+\makeatother \clearpage{\pagestyle{plain}\cleardoublepage}
+
+% Define pagestyle
+\pagestyle{fancy}
+\fancyhf{}
+\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
+\fancyhead[LO]{}
+\fancyhead[RE]{\leftmark}
+\fancyfoot[LE,RO]{\thepage}
+
+% Dutch style of paragraph formatting, i.e. no indents.
+\setlength{\parskip}{1.3ex plus 0.2ex minus 0.2ex}
+\setlength{\parindent}{0pt}
+
+% Less detailed TOC
+\setcounter{tocdepth}{1}