\chapter{Interactively Controlled File System}
\label{icfs}

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. At the same time, it allows for broader, more general rules, which helps to reduce the choice fatigue of the user.

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 two buttons: \emph{Allow] and \emph{Deny}.

\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. 

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:

\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 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. To mitigate this issue, the rule had to be somewhat relaxed in way that compromises the least amount of user data.

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. 

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

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