\chapter{Interactively Controlled File System}

In this section we present the solution developed as a part of this thesis, named \emph{Interactively Controlled File System} (or ICFS for short).

ICFS is a filesystem layer that gives user direct command over its access control. Instead of relying on static policies or rules, it prompts the user for the access control decision via graphical interface. 

ICFS is user-friendly and trivially easy to use. It does not introduce any new terminology or complex access control management strategies. The graphical interface is intuitive and self-explanatory. ICFS is configured on the fly: as programs request access, the user's decisions are recorded and later reused. There is no need for any configuration besides installation and choosing a directory to control. It operates on the level of individual processes and files, ensuring high granularity. 

\iffalse

At the same time, it allows for broader, more general rules, which helps to reduce the choice fatigue of the user.

\fi

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{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:

\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.
	\item \emph{Allow this time}, that will allow the requesting process to access the file.
	\item \emph{Deny}, that will deny all access to the file.
\end{itemize}

\missingfigure[figwidth=9cm ,figcolor=white]{ICFS access dialogue}

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.



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.

\fi

