Updated the "Least Privilege" section

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 no previous decisions were made regarding process's access to the file, window with 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 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:
 
 \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.
@@ -28,7 +28,11 @@ As promised, the access control model of ICFS is trivially simple. It features p
 
 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.
+Decisions made in the dialogues are recorded and later reused when processes access files again. 
+
+Behaviour changes slightly, if the operation is performed on a directory or a symbolic link: If the file is a directory, only changing the access mode and removal require permission from the user. With symbolic links, following is always permitted.
+
+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:
 
@@ -47,13 +51,17 @@ Following the principle of the least privilege and being user-friendly at the sa
 
 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.
+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 a filesystem object is made, a kind of privilege escalation is attempted with the access dialogue. Assuming the user's decisions are intelligent, the principle of the least privilege would be followed perfectly in this case.
 
-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.
+However, if the above rules were followed literally, the ICFS would be \emph{very} tiring to use. To mitigate this issue, the rule had to be somewhat relaxed in way that compromises the least amount of user 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.
+Firstly, unlike POSIX access control policies, ICFS does not give an ability to hide the directory structure from processes. 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. 
 
-\todo[inline, author={\textbf{TODO}}]{Justify automatically giving permissions on file creation.} 
+One more relaxation we decided to make was allowing processes to create files without restriction. This decision comes from an observation that most programs often open auxiliary and temporary files to functions. For example, one program that is particularly notorious for such behaviour is the pdfLaTeX compiler. Out of 21 files in the source directory for this thesis, only 10 files are actually human-editable and are not intermediary output of the compiler. The amount of decision-making required for the user to give all appropriate permissions in this case is more than double than the amount of files where the actual data is stored.
+
+Because of the overwhelming amount of additional files that programs need to create to function, we decided that the risk of letting the program create arbitrary files is less important. Indeed, if the process creates a new file, than it can't possibly extract any additional data from the system. 
+
+However, this decision actually opens up some possibilities for the malicious processes to disrupt functioning of the other processes. We discuss those in the \autoref{eval:limit} of the \autoref{eval}.
 
 \iffalse