Added more explanation to the approach

approach.tex

@@ -16,7 +16,7 @@ It is backwards compatible: ICFS overrides the regular system call interface usi
 
 \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 POSIX permissions of an existing file that is not a directory or a symbolic link, and this process does not already have access to this file, a dialogue is displayed with three options:
+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 POSIX permissions of an existing file that is not a directory or a symbolic link, and no previous decisions were made regarding process's access to the file, window with a dialogue is displayed with three options:
 
 \begin{itemize}
 	\item \emph{Allow}, that will allow this process and any other process that is started with the same executable to access the file.
@@ -24,16 +24,50 @@ As promised, the access control model of ICFS is trivially simple. It features p
 	\item \emph{Deny}, that will deny all access to the file.
 \end{itemize}
 
-\missingfigure[figcolor=white]{ICFS access dialogue}
+\missingfigure[figwidth=9cm ,figcolor=white]{ICFS access dialogue}
 
-\todo[inline, author={\emph{Draft note}}]{Too much stuff per section? Divide by the issues from previous chapter?} 
+We will later refer to these windows as \emph{access dialogues}.
+
+Decisions made in the dialogues are recorded and later reused when processes access files again. If a process attempts to create a file, it is automatically granted permanent access to the file it has created.
+
+This model obviously mitigates at least four of the six previously laid out problems of existent solutions:
+
+\begin{itemize}
+	\item Usage of such an access control is entirely reactive. The user does not need to configure anything until the filesystem access is actually needed. 
+	\item User can choose to only grant permissions temporarily, using the ``Allow this time'' option.
+	\item The solution is designed specifically to work with single-user environments.
+	\item Provides a very fine granularity of permissions. ICFS can deny or allow access of a process to a specific file, which is way finer than 
+\end{itemize}
+
+The two remaining criteria will be discussed in more detail in the next section.
+
+\section{Least privilege and user-friendliness}
+
+Following the principle of the least privilege and being user-friendly at the same time, is the single biggest challenge of this work. Unfortunately, those features are mutually exclusive most of the time.
+
+In order to stay user-friendly, ICFS needs to keep the number of dialogues to minimum. This means we have to avoid prompting for actions that are likely safe. However, we still want to follow the principle of the least privilege, and avoid allowing any kind of privileges to all software by default.
+
+When ICFS is started for the first time, no user decisions are known yet. At this point, no processes have access to any file controlled by ICFS. When a new attempt to access files is made, a kind of privilege escalation is attempted with the access dialogue. Assuming the user's decisions are intelligent, in such case the principle of the least privilege would be followed perfectly.
+
+However, if the above rules were followed literally, the ICFS would be \emph{very} tiring to use. Suppose a process attempts to access \verb|/home/user/Documents/main.tex|, that is a symbolic link to \verb|/home/user/Documents/real_main.tex|. According to the rules we have just defined, the process would need access to all directories in the path to the \verb|main.tex| file, but it would also need access to the \verb|main.tex| file itself, all directories in the path to \verb|real_main.tex| and finally \verb|real_main.tex|. The problem, is that only one out of five files that we need access to actually contains data.
+
+So, that's where the exception for symbolic links and directories comes from. The only thing that a malicious process can gain from this relaxation of the original restrictions is the ability to see the directory structure, which is unlikely to contain any kind of sensitive data. Of course, modification and removal of directories and symbolic links still requires an appropriate permission, since an attacker may modify them to represent completely different data, while other processes would be none the wiser.
+
+\todo[inline, author={\textbf{TODO}}]{Justify automatically giving permissions on file creation.} 
+
+\iffalse
+
+However, if the above rules were followed literally, the ICFS would be \emph{very} tiring to use. To illustrate this, let's consider the following example: the user has a \TeX document in the \verb|/home/user/Documents/main.tex| file. Now they want to edit the file using their text editor of choice, \verb|vim|. At the first glance, it might seem like the user would be accessing just one file, but the reality is that they are actually accessing four files: three directories and one file. If the above rules were followed literally, \verb|vim| would require permission to each file in the path\footnote{Assuming ICFS is mounted at root. This is not recommended, even if possible.} to actually read data from a single file.
+
+Situations like this are the reason ICFS does not require permission for the process to access directories. The only thing that a malicious process can gain from this relaxation of the original restrictions is the ability to see the directory structure, which is unlikely to contain any kind of sensitive data.
+
+Now, let's slightly change our example. Now, let \verb|/home/user/Documents/main.tex| be a symbolic link to the \verb|/home/user/Documents/real_main.tex| file. From standpoint of the user it might seem like they are accessing just one file.
 
-Decisions made in the dialogues are recorded and later reused when processes access files again.
 
-On the other hand, if a process attempts to create a file, it is automatically granted permanent access to the file it has created.
 
 We chose this model because of its simplicity. Having more options in the dialogue induced heavy choice fatigue of the user, since programs typically open a lot of files throughout their runtime. Even simple text editors open lock and backup files besides the target file. Programs like TeXstudio or programming IDEs open dozens of files simultaneously, since they need all kinds of temporary and configuration files.
 
 We chose to give processes unlimited access to directories and symbolic links because they do not contain any data on their own. Having to grant access to every folder on the path to the file is simply too tedious for anyone.
 
-The choice to not require access granting for file \emph{creation} is also based in simplicity. If a process can't modify or edit any existing data by creating new files, then there is little use in restricting it.
+\fi
+