Updated the pdf

approach.tex

@@ -14,6 +14,20 @@ At the same time, it allows for broader, more general rules, which helps to redu
 
 It is backwards compatible: ICFS overrides the regular system call interface using FUSE framework, which means that any software that wishes to use the files ICFS protects has to respect it's policies. Its interactivity combined with the ability to only grant permissions for the lifetime of a specific process makes proxy attacks very difficult to go unnoticed.
 
+\section{Usage}
+
+To use ICFS, the user only needs to select a directory that they wish to protect, and run:
+
+\begin{minted}{bash}
+	icfs path/to/directory
+\end{minted}
+
+Upon running this command, ICFS will be mounted over the chosen directory, and access to every file in it will from now on be controlled by ICFS.
+
+Although it has the words ``File System`` in the name, ICFS is not an alternative to real filesystems like ext4 or btrfs. Instead, it is a \emph{filesystem layer}, that sits in between the actual on-disk filesystem and the virtual file system presented to the processes. It acts as an intermediary that intercepts the filesystem calls and enforces it's own logic. The exact details of the implementation of such mechanism will be discussed in the \autoref{impl:fuse}.
+
+What is important for this section however, is that from the standpoint of the user processes it looks just like the underlying filesystem would. Processes would just see the same folder that once was in ICFS's place.
+
 \section{Access Control Model}
 
 As promised, the access control model of ICFS is trivially simple. It features processes as it's subjects, and files as objects. Whenever a process attempts to open, remove or change the access mode of an existing file and no previous decisions were made regarding process's access to the file, window with a dialogue is displayed with three options:

implementation.tex

@@ -1,6 +1,28 @@
 \chapter{Implementation}
 
-This chapter describes the software design and architecture, and the way that they help to solve the problem. The following sections describe the FUSE framework, different methods used to store access permissions of processes and finally the way the chosen architecture is designed to resist unauthorised access to the filesystem.
+This chapter describes the software design and architecture, and the way that they help to solve the problem. The following sections describe the FUSE framework, different methods used to store access permissions of processes and the way the chosen architecture is designed to resist unauthorised access to the filesystem.
 
 \section{FUSE framework}
+\label{impl:fuse}
 
+In order to control the filesystem operations performed by the processes, ICFS uses FUSE (Filesystem in Userspace) framework\cite{FUSE} to override the filesystem call interface. FUSE allows to implement custom filesystems or layers in userspace, which makes it very flexible and easy to use. FUSE defines an API that can be implemented by the developers of the filesystems. After the implementation (which will be referred to as \emph{FUSE application}) is launched, it mounts its filesystem at the specified location, and replaces the filesystem calls with its own methods, according to the FUSE API.
+
+ICFS implements the API in C, using libfuse3 library. It then launches the FUSE daemon through fuse\_main() function, which sets up the filesystem, and performs all the communication between the kernel and the FUSE application. FUSE does not directly replace syscalls, but instead communicates with the kernel via a special device in /dev directory, called /dev/fuse. This device uses a special protocol to communicate with the kernel and translate filesystem calls into FUSE API method invocations.
+
+ICFS does not have a backing store (a separate filesystem that contains actual data). Instead, it uses the so-called passthrough mode, where filesystem calls are forwarded to the original filesystem, if access control policies allow them.
+
+\subsection{Hiding the underlying directory}
+
+\todo[inline, author={\textbf{Draft note}}]{Write how the source directory is protected}
+
+\section{Permission tables}
+
+\todo[inline, author={\textbf{Draft note}}]{Write how permission tables scheme was chosen}
+
+\subsection{Temporary permissions}
+
+\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how temporary permission tables work. Specifically, how temporary permissions work with the cc library and start time process identification}
+
+\subsection{Permanent permissions}
+
+\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how permanent permission tables work. Specifically, how permanent permissions work with sqlite3.}

literatura.bib

@@ -82,4 +82,9 @@
 @online{ANDR11PERM,
 	title = {Permissions updates in Android 11},
 	url = {https://developer.android.com/about/versions/11/privacy/permissions},
+}
+
+@online{FUSE,
+	title = {FUSE — The Linux Kernel documentation},
+	url = {https://www.kernel.org/doc/html/latest/filesystems/fuse.html},
 }