ICFS-thesis/approach.tex

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

This chapter presents the solution developed for this thesis, the Interactively Controlled File System (ICFS), a user-centric filesystem layer designed to enhance access control through real-time user input.

ICFS provides users with direct control over filesystem access decisions. Unlike traditional systems relying on static policies, ICFS dynamically prompts users for authorization via a graphical interface, ensuring decisions align with immediate contextual needs.

Key Features:

\begin{itemize}
	\item User-Friendly Design: Requires no prior configuration or specialized knowledge. The intuitive interface eliminates complex terminology, enabling seamless interaction.
	\item Dynamic Policy Enforcement: Permissions are established on-demand and stored for future reference, minimizing repetitive prompts.
	\item Granular Control: Policies apply at the process-file level, with options to generalize rules for broader categories, reducing user fatigue.
	\item Backward Compatibility: Implemented via the FUSE framework, ICFS intercepts system calls without altering existing software workflows. 
\end{itemize}

\section{Usage}

To deploy ICFS, the user selects a target directory and executes the command as shown in \autoref{icfs:usage:cmd}

\begin{figure}[!ht]
\begin{minted}{bash}
icfs <FUSE arguments> [mounpoint] [permission database] <ICFS arguments>
\end{minted}
\caption{Command that mounts ICFS over the folder denoted as [mounpoint], while using the permanent permission database stored in the file denoted as [permission database]. <ICFS arguments> and <FUSE arguments> denote ICFS arguments and libfuse arguments respectively.}
\label{icfs:usage:cmd}
\end{figure}

This mounts ICFS over the specified directory, enforcing access control for all subsequent interactions. While the name includes "File System," ICFS operates as a filesystem layer , intermediating between the physical filesystem (e.g., ext4) and user processes. It preserves the appearance of the original filesystem while enforcing its own access logic (implementation details in \autoref{impl:fuse}).

\section{Access Control Model}
\label{icfs:model}

ICFS adopts a straightforward access control model:

\begin{itemize}
	\item Subjects: Processes requesting access.
	\item Objects: Files or directories undergoing access attempts.
\end{itemize}

When a process requests access (e.g., open, modify, delete) to a file without pre-existing permissions, ICFS generates an access dialogue (see Figure \ref{fig:dialogue}).

\begin{figure}[H]
	\centering
	\includegraphics[width=0.6\linewidth]{./images/icfs-dialogue-window.png}
	\caption{ICFS Access Dialogue: Displays the process executable name, PID, and target file path. Users may adjust the file scope, toggle permanent permissions, or grant/deny access.}
	\label{fig:dialogue}
\end{figure}

The dialogue contains three functional elements:

\begin{itemize}
	\item Access Grant Buttons.
	\begin{itemize}
		\item Yes Button : Grants temporary access to the requested file to the requesting process only. If the user selects this option, the process is allowed to proceed with the requested access (e.g., read, write).
		\item No Button : Denies access to the file for the current process. The filesystem returns an error (e.g., EACCES) to the requesting process, mimicking standard permission denial behavior.
	\end{itemize}
	\item Permanent Permission Checkbox: A toggle labelled "Permanent" allows the user to persist the access decision beyond the current process.
	If checked , the permission rule (allow/deny) is stored in a local configuration database. The rule then applies to all future access attempts by processes (and any of their child processes) with an executable filename matching the requesting process.
	If unchecked , the decision applies only to the requesting process and it's child processes. That is, the process can actually access the file multiple times with this permission.
	Permissions granted with this box toggled on (off) will from now on be referred to as ''permanent`` (''temporary``).
	\item File Path Substitution Field: A text input field pre-filled with the absolute path of the requested file. Users may edit this field to modify scope of the permission (e.g., granting access to all files in the parent directory instead of a single file).
\end{itemize}

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 temporary access to the file it has created.

This model addresses five key limitations of traditional systems:

\begin{itemize}
	\item Reactive Configuration: No upfront setup required; permissions emerge organically.
	\item Temporary Permissions: Users may limit access to a single instance.
	\item Scalable Granularity: Policies adapt from specific files to broader categories.
\end{itemize}

The remaining two criteria are analysed in the next section.

\section{Least Privilege vs. Usability}

Balancing the principle of least privilege with usability posed the greatest design challenge. Strict enforcement -- prompting for every access attempt -- would minimize risk but overwhelm users.

To reduce friction, ICFS needs to keep the number of dialogues to minimum. This necessitates avoiding prompts for actions likely to be safe. However, we still aim to avoid granting excessive privileges by default.

When ICFS is initially started, no user decisions are known, and thus no processes have access to protected files. Each new access attempt triggers a privilege escalation request via the access dialogue.

Applying this rule strictly to all filesystem objects -- including directories and symbolic links -- with intelligent user decisions, would perfectly adhere to the principle of least privilege.

However, such strictness would render ICFS excessively cumbersome to use. To mitigate this, the rule has been relaxed to compromise user data as little as possible.

Firstly, Unlike POSIX, ICFS does not restrict directory visibility. While this exposes file structures, directory names rarely contain sensitive data.

Second, processes are permitted to create files without restriction. This decision is based on the observation that many programs create auxiliary and temporary files. For instance, the pdfLaTeX compiler creates 21 files in the source directory for this thesis, only 10 of which are human-editable; the remaining files are intermediary output of the compiler. Requiring the user to grant permissions for all these files would more than double the decision-making burden.

While this approach increases the potential for malicious processes to disrupt other processes, the risk is considered lower than the burden of constantly prompted permission requests. We discuss these limitations in \autoref{eval:sec}.

Thirdly, all access permissions apply to the child processes too. Since only the parent process has control over starting its children, it is theoretically safe to presume that non-malicious processes won't spawn malicious child processes. Of course, this presumption is not necessarily true in reality: programs contain a plethora of bugs some of which might as well allow for arbitrary code execution, and thus starting of unwanted programs as its children.

However, we decided that the burden caused by having to allow access to all its children is way too high. For example, the Neovim text editor may spawn up to five additional child processes that analyse the opened file, such as code linters, formatters and debuggers. We discuss potential threats that relate to this rule in \autoref{eval:sec}.


\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