Update :)

approach.tex

@@ -1,70 +1,95 @@
 \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).
+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 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 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.
 
-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.
+Key Features:
 
-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.
+\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. 
+	\item Time-bound permissions ??
+\end{itemize}
 
 \section{Usage}
 
-To use ICFS, the user only needs to select a directory that they wish to protect, and run:
+To deploy ICFS, the user selects a target directory and executes:
 
 \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.
+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}
 
-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:
+ICFS adopts a straightforward access control model:
 
 \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 
+	\item Subjects: Processes requesting access.
+	\item Objects: Files or directories undergoing access attempts.
 \end{itemize}
 
-The two remaining criteria will be discussed in more detail in the next section.
+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}).
 
-\section{Least privilege and user-friendliness}
+%\missingfigure[figwidth=9cm ,figcolor=white]{ICFS access dialogue}
 
-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.
+\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}
 
-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.
+The dialogue contains three functional elements:
 
-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.
+\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 labeled "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 with an executable filename matching the requesting process.
+	If unchecked , the decision applies only to the requesting process. 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}
 
-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.
+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.
 
-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. 
+This model addresses five key limitations of traditional systems:
 
-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.
+\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}
 
-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. 
+The remaining two criteria are analysed in the next section.
 
-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}.
+\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:limit} of \autoref{eval}.
 
 \iffalse
 

evaluation.tex

@@ -18,24 +18,27 @@ Specifically will include:
 \say{does using this fs break other programs?}
 \newline
 
-Mostly - no. The biggest issue right now are (ironically) file trackers like \verb|tracker-miners|. Those are programs that scan the filesystem (e.g. to make file search more efficient). The problem is that the current version of the software does not allow changing the scope of permissions you are giving (e.g. you can't just give permission to access the entire filesystem).
+\sout{Mostly - no. The biggest issue right now are (ironically) file trackers like tracker-miners. Those are programs that scan the filesystem (e.g. to make file search more efficient). The problem is that the current version of the software does not allow changing the scope of permissions you are giving (e.g. you can't just give permission to access the entire filesystem).
 
-The solution would be to give an ability to adjust the scope inside the permission dialogue. Everything on the ``backend'' side is ready for this change, but... since I am using zenity it does not easily give me the ability to just add another element to the dialog. Probably a custom dialogue program has to be written, or multiple dialogues would have to be shown(e.g. standard one with Allow/Allow this time/Deny with a ``more options'' button, and then a second zenity dialogue with more detailed configurations) to solve the issue.
-\newline
+The solution would be to give an ability to adjust the scope inside the permission dialogue. Everything on the ``backend'' side is ready for this change, but... since I am using zenity it does not easily give me the ability to just add another element to the dialog. Probably a custom dialogue program has to be written, or multiple dialogues would have to be shown(e.g. standard one with Allow/Allow this time/Deny with a ``more options'' button, and then a second zenity dialogue with more detailed configurations) to solve the issue.}
+
+Now it does not.\newline
 
 \say{..like whether it interferes with programs using auxiliary files..}
 \newline
 
 No, this issue is solved. Because the programs that use such files are typically the ones that create them, they automatically get the permissions to access them.
 
-In fact, I am writing this thesis inside of a folder managed by ICFS, and even despite TeX's notorious love for auxiliary files it works just fine.
+In fact, I am writing this thesis inside of a folder managed by ICFS, and even despite TeX's notorious love for auxiliary files it works just fine.\newline
 
 \say{..usability of terminal programs (grep is a particularly nasty one for this specific project)}
 \newline
 
-Yes, this still is an issue. The problem of \verb|grep| is the same as with file trackers, so I will skip it.
+\sout{Yes, this still is an issue. The problem of grep is the same as with file trackers, so I will skip it.}
 
-As for regular terminal programs, I see these possible solutions:
+This is mostly solved in my experience. It wasn't as annoying to use the terminal programs as I initially expected.
+
+As for terminal programs, I see these possible \sout{solutions} improvements:
 \begin{itemize}
 	\item Use SID and TTY to identify a shell session (like \verb|sudo| does).
 \end{itemize}

implementation.tex

@@ -1,29 +1,41 @@
 \chapter{Implementation}
 \label{impl}
 
-This chapter describes the software design and architecture, and the way that they help to solve the problem. The following sections describe the FUSE framework, different methods used to store access permissions of processes and the way the chosen architecture is designed to resist unauthorised access to the filesystem.
+This chapter outlines the software design and architecture of ICFS, detailing how these elements address the challenge of fine-grained access control. Subsequent sections introduce the FUSE framework, methods for managing process-specific permissions, and the architectural strategies employed to mitigate unauthorised filesystem access.
 
 \section{FUSE framework}
 \label{impl:fuse}
 
-In order to control the filesystem operations performed by the processes, ICFS uses FUSE (Filesystem in Userspace) framework\cite{FUSE} to override the filesystem call interface. FUSE allows to implement custom filesystems or layers in userspace, which makes it very flexible and easy to use. FUSE defines an API that can be implemented by the developers of the filesystems. After the implementation (which will be referred to as \emph{FUSE application}) is launched, it mounts its filesystem at the specified location, and replaces the filesystem calls with its own methods, according to the FUSE API.
+To regulate filesystem operations, ICFS employs the FUSE (Filesystem in Userspace) framework\cite{FUSE}, which intercepts filesystem calls. FUSE enables the creation of custom filesystems or layers in user space, offering flexibility and ease of implementation. It provides an API for developers to define filesystem behavior. Once implemented (hereafter termed the FUSE application ), the system mounts the custom filesystem at a specified location, substituting standard filesystem operations with methods defined by the API.
 
-ICFS implements the API in C, using libfuse3 library. It then launches the FUSE daemon through fuse\_main() function, which sets up the filesystem, and performs all the communication between the kernel and the FUSE application. FUSE does not directly replace syscalls, but instead communicates with the kernel via a special device in /dev directory, called /dev/fuse. This device uses a special protocol to communicate with the kernel and translate filesystem calls into FUSE API method invocations.
+ICFS implements this API in C using the libfuse3 library. It initializes the FUSE daemon via the \verb|fuse_main()| function, which manages communication between the kernel and the FUSE application. Rather than directly overriding system calls, FUSE interacts with the kernel through \verb|/dev/fuse|, a specialized device file that translates filesystem requests into API method invocations using a dedicated protocol.
 
-ICFS does not have a backing store (a separate filesystem that contains actual data). Instead, it uses the so-called passthrough mode, where filesystem calls are forwarded to the original filesystem, if access control policies allow them.
+ICFS does not have a backing store (a separate filesystem that contains actual data). Instead, it functions as a so-called passthrough filesystem, where system calls are forwarded to the original filesystem, if access control policies allow them.
 
-\subsection{Hiding the underlying directory}
-
-\todo[inline, author={\textbf{Draft note}}]{Write how the source directory is protected}
+To enforce access restrictions, ICFS mounts directly over the target directory, intercepting all access requests directed to it. As part of Linux’s Virtual Filesystem (VFS) architecture, processes interacting with the protected directory are routed through ICFS. However, ICFS retains direct access to the underlying files by opening the directory with the \verb|O_PATH| flag before mount. Subsequent operations are executed using "at"-suffixed system calls like \verb|openat()|, performed directly at the file descriptor level\cite{MANOPEN}, which bypasses ICFS's own layer.
 
 \section{Permission tables}
 
-\todo[inline, author={\textbf{Draft note}}]{Write how permission tables scheme was chosen}
+To enforce an access control policy over time, filesystem needs to store user decisions in an appropriate data structure. As described in \autoref{icfs:model}, ICFS can give out two types of permissions: temporary and permanent. To accommodate this access control model, ICFS implements two data structures: a temporary permissions table, and a permanent permissions table, which we describe in detail in \autoref{impl:temp} and \autoref{impl:perm} respectively.
 
 \subsection{Temporary permissions}
+\label{impl:temp}
 
-\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how temporary permission tables work. Specifically, how temporary permissions work with the cc library and start time process identification}
+To function, temporary permissions storage should contain all information needed to identify the process, and associate the files to which the access is denied or allowed with it. We chose to keep track of processes by comparing the following characteristics:
+
+\begin{itemize}
+	\item Process ID: Number that uniquely identifies a process on Linux systems.
+	\item Start time: The time the process started after system boot. The value is expressed in clock ticks.
+\end{itemize}
+
+The process is considered the same if and only if both characteristics match.
+
+At first, it might seem that factoring in start time is excessive. However, only using PID as the only identifying property of a process is problematic: PID is only unique among the currently running processes, not across the entire uptime of the system. Processes can not only acquire the PID of another, already finished process, but also attempt to request a specific PID. The start time is looked up in procfs by PID, which is provided by libfuse.
+
+The temporary permissions table consists of tuples $(pid, starttime, allowed, denied)$, where $allowed$ and $denied$ are sequences of files, that the process is allowed or denied to access respectively.
+
+In our implementation, entries are organised in a hash map, with PIDs as keys. This provides quick lookup of entries, that is much needed for filesystem operations. ICFS uses the hash map implementation from the Convenient Containers library \cite{CC}, that is well-tested and has an intuitive interface, which has helped to simplify the development.
 
 \subsection{Permanent permissions}
+\label{impl:perm}
 
-\todo[inline, caption={Write how permission tables work}, author={\textbf{Draft note}}]{Write how permanent permission tables work. Specifically, how permanent permissions work with sqlite3.}

literatura.bib

@@ -67,24 +67,46 @@
 @online{FLATPAK,
 	title = {FlatPak - The future of application distribution on Linux.},
 	url = {https://flatpak.org/},
+	organization  = {Flatpak Team},
+	year = {2025}
 }
 
 @online{SNAP,
 	title = {Snapcraft - Snaps are universal Linux packages.},
 	url = {https://snapcraft.io/},
+	organization = {Canonical Ltd.},
+	year = {2025}
 }
 
 @online{APPIMAGE,
 	title = {AppImage | Linux apps that run anywhere },
-	url = {https://flatpak.org/},
+	url = {https://appimage.org/},
+	author = {Simon Peter},
+	year = {2019}
 }
 
 @online{ANDR11PERM,
 	title = {Permissions updates in Android 11},
 	url = {https://developer.android.com/about/versions/11/privacy/permissions},
+	year = {2025}
 }
 
 @online{FUSE,
 	title = {FUSE — The Linux Kernel documentation},
 	url = {https://www.kernel.org/doc/html/latest/filesystems/fuse.html},
+}
+
+@manual{MANOPEN,
+	title      = {open(2) System Calls Manual},
+	organization  = {Free Software Foundation},
+	edition   = {6.9.1},
+	year       = 2024,
+	month      = 5,
+}
+
+@online{CC,
+	title = {GitHub - JacksonAllan/CC: A small, usability-oriented generic container library.},
+	author = {Jackson L. Allan},
+	year = {2025},
+	url = {https://github.com/JacksonAllan/CC}
 }

main-en.tex

@@ -12,6 +12,12 @@
 \usepackage[textwidth=20mm]{todonotes}
 %quotes
 \usepackage{dirtytalk}
+%fancy bibliography
+\usepackage[
+backend=biber,
+style=ieee,
+]{biblatex}
+\addbibresource{literatura.bib}
 
 
 
@@ -46,7 +52,12 @@
 %fancy references
 \usepackage{cleveref} 
 %strikethorugh
-\usepackage{ulem}
+\usepackage[normalem]{ulem}
+
+\usepackage{subcaption}
+
+% Images
+\graphicspath{ {./images/} }
 
 % -------------------
 % --- REMOVE BEFORE PUBLISHING
@@ -312,8 +323,8 @@ or deny access to a filesystem object by a specific process to the user.
 \thispagestyle{empty}
 \clearpage
 
-\bibliographystyle{plain}
-\bibliography{literatura} 
+%\bibliographystyle{plain}
+\printbibliography
 
 %Prípadne môžete napísať literatúru priamo tu
 %\begin{thebibliography}{5}

motivation.tex

@@ -37,7 +37,18 @@ Another, similar solution can be found in the Android operating system. Here, al
 
 When an app need permission to access the shared storage (part of the filesystem, common to all applications), an overlay is displayed, prompting the user for their decision on whether to allow or deny access to user's files. Notably, this approach avoids the problem of granting permissions up front, and always informs the user about the permissions that the app wishes to have.
 
-\missingfigure[figcolor=white]{Picture of an Android permissions dialogue.}
+\begin{figure}[H]
+	\centering
+	\begin{subfigure}[b]{0.4\linewidth}
+		\includegraphics[width=\linewidth]{./images/permission-dialogue-organic-maps.jpg}
+		\caption{}
+	\end{subfigure}
+	\begin{subfigure}[b]{0.5\linewidth}
+		\includegraphics[width=\linewidth]{./images/permission-dialogue-smart-scan.jpg}
+		\caption{}
+	\end{subfigure}
+	\caption{Permissions dialogues in Android 14: The location access permission dialogue (a) shows three options: ''While using the app``, ''Only this time`` and ''Don't allow``. The media access permission dialogue also has three, but different options: ''Allow limited access``, ''Allow all'' and ''Don't allow``}
+\end{figure}
 
 Furthermore, starting in Android 11, whenever an app requests a permission related to location, microphone, or camera, the user-facing permissions dialogue contains an option called ''Only this time``. If the user selects this option in the dialogue, the app is granted a temporary one-time permission.\cite{ANDR11PERM}