We all hope for this thesis. Hopefully, the final commit.

accesscontrol.tex

@@ -7,7 +7,7 @@ By default, UNIX-like operating systems only provide simplistic Discretionary Ac
 
 The policy used by traditional UNIX systems is based on the concepts of \textit{file owner}, \textit{group of a file}, and \textit{others}. For each file, the access rights for these three categories can be specified independently using a so-called access mode. The access mode is a bitmask which specifies whether the file owner, the group of the file, and others have read, write, or execute permissions.
 
-Each process has it's own \textit{Effective User ID} (EUID), that identifies the user that initiated it. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
+Each process has its own \textit{Effective User ID} (EUID),  the user that the process is running on behalf of. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
 
 \begin{itemize}
 	\item If the process's effective user ID matches the file owner, the file owner's access mode is used.
@@ -16,21 +16,20 @@ Each process has it's own \textit{Effective User ID} (EUID), that identifies the
 	
 \end{itemize}
 
-The access mode is stored in the file's inode, and is set by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
+The access mode is stored in the file's inode,  and can be changed by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
 
 Later, a feature called Access Control Lists (ACL) was introduced to many UNIX-like operating systems and eventually included in the POSIX standard. ACLs provide the ability to control file permissions of specific users, rather than just owner, group and others. Similar to the classic UNIX access control policies, only processes running with the user ID that matches the owner user ID of a file can change its ACLs.
 
 
-\section{The Inherent Flaw}
+\section{The Inherent Flaw of User-Centric Access Control}
 
 Although this kind of access control solutions has been proven to be helpful in multi-user environments, it is obviously insufficient to protect against an attack performed by a process initiated by the same user. 
 
-The fundamental weakness of the traditional UNIX DAC model, and even its extension with ACLs, lies in its reliance on user identity as the primary access control decision point. While effective at separating access between different users, it provides little to no protection within a user’s own account. This deficiency is particularly problematic in modern computing environments where a user’s processes are increasingly complex and often involve downloaded or third-party code.
+The fundamental weakness of the traditional UNIX DAC model, and even its extension with ACLs, lies in its reliance on user identity as the primary access control decision point. While effective at separating access between different users, it provides little to no protection within a user's own account. This deficiency is particularly problematic in modern computing environments where a user's processes are increasingly complex and often involve downloaded or third-party code.
 
-This vulnerability stems from the “all or nothing” nature of user ownership. A process running with user’s EUID inherits all of user’s privileges, treating all files they own as equally accessible. There’s no way to restrict a specific process, even one initiated by the user themselves, from accessing certain files or performing certain operations. 
+This vulnerability stems from the ``all or nothing'' nature of user ownership. A process running with user's EUID inherits all of user's privileges, treating all files they own as equally accessible. There's no way to restrict a specific process, even one initiated by the user themselves, from accessing certain files or performing certain operations. 
 
 These limitations highlight the need for more sophisticated access control mechanisms that go beyond simple user identity and consider the context and trustworthiness of the process attempting to access a resource. Mandatory Access Control (MAC) and sandboxing technologies are emerging solutions aiming to address these shortcomings by introducing finer-grained control over process privileges and resource access. The following chapter will explore these alternatives in detail.
 
-\todo[inline, author={\textbf{Draft note}}]{Talk more about the threat model?}
 
 

appendixA.tex

@@ -0,0 +1,5 @@
+\chapter*{Appendix A: source code}
+\addcontentsline{toc}{chapter}{Príloha A}
+\label{code}
+
+Source code of ICFS can be found on the CD attached to this thesis, and on the internet at \url{https://git.umbrasolis.de/fedir/ICFS}. All necessary installation and usage information is provided in the \verb|README.md| file. Description of source code parts is available in \verb|CONTENTS.md| file.

approach.tex

@@ -1,96 +1,97 @@
 \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 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 authorisation 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. 
+Key Features:
 
-\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.
+\begin{itemize}
+	\item User-Friendly Design: Requires no prior configuration or specialised knowledge. The intuitive interface eliminates complex terminology, enabling seamless interaction.
+	\item Dynamic Policy Enforcement: Permissions are established on-demand and stored for future reference, minimising repetitive prompts.
+	\item Granular Control: Policies apply at the process-file level, with options to generalise 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 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 the command as shown in \autoref{icfs:usage:cmd}
 
+\begin{figure}[!ht]
 \begin{minted}{bash}
-	icfs path/to/directory
+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}
 
-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 three options:
+ICFS adopts a straightforward access control model:
 
 \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.
+	\item Subjects: Processes requesting access.
+	\item Objects: Files or directories undergoing access attempts.
 \end{itemize}
 
-\missingfigure[figwidth=9cm ,figcolor=white]{ICFS access dialogue}
+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}).
 
-We will later refer to these windows as \emph{access dialogues}.
+\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}
 
-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:
+The dialogue contains three functional elements:
 
 \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 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.
+		\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). If user intends to allow the process to all files in a directory, its path has to end with ``\verb|/|'' character.
 \end{itemize}
 
-The two remaining criteria will be discussed in more detail in the next section.
+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.
 
-\section{Least privilege and user-friendliness}
+To resolve situations, where user sets conflicting permissions with different scopes, only the more specific permission's effect is applied. For example, if user first allows a process to access \verb|~/Documents/book.pdf|, but later also denies access to \verb|~/Documents/|, then the process is allowed to access \verb|~/Documents/book.pdf|, but no other files in \verb|~/Documents/|.
 
-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.
+This model addresses five key limitations of traditional systems:
 
-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.
+\begin{itemize}
+	\item Reactive Configuration: No upfront setup required; permissions emerge organically.
+	\item Temporary Permissions: Users may limit access to a single instance of a program.
+	\item Scalable Granularity: Policies adapt from specific files to broader categories.
+\end{itemize}
 
-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.
+The remaining two criteria are analysed in the next section.
 
-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.
+\section{Least Privilege vs. Usability}
 
-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. 
+Balancing the principle of least privilege with usability posed the greatest design challenge. Strict enforcement -- prompting for every access attempt -- would minimise risk but overwhelm users.
 
-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.
+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.
 
-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. 
+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.
 
-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}.
+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.
 
-\iffalse
+Firstly, Unlike POSIX, ICFS does not restrict directory visibility. While this exposes file structures, directory names rarely contain sensitive data.
 
-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.
+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.
 
-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.
+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:create}.
 
-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
+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.

conclusion.tex

@@ -2,6 +2,12 @@
 \addcontentsline{toc}{chapter}{Conclusion} % rucne pridanie do obsahu
 \markboth{Conclusion}{Conclusion} % vyriesenie hlaviciek
 
-\todo[inline, author={\textbf{Draft note}}]{This chapter is \emph{very} incomplete.} 
+This thesis introduced the Interactively Controlled File System (ICFS), a novel approach to filesystem access control designed to address the inherent limitations of traditional discretionary access control (DAC) mechanisms in Linux environments. By placing access control decisions directly in the hands of users through real-time graphical prompts, ICFS bridges the gap between coarse-grained flexibility of DAC and the rigid complexity of mandatory access control (MAC) frameworks. The system’s design prioritises usability without compromising security, enabling users to grant or deny process-specific permissions dynamically while maintaining backward compatibility with existing software workflows via the FUSE framework.
 
-In conclusion, the overall value and benefits of the solution is discussed(reiterated \verb|:)|). 
+The implementation of ICFS demonstrates that granular access control can be achieved through an interactive model. By allowing temporary permissions and scalable policy generalisation, the system minimises both user burden and the risk of overprivileged processes -- a critical weakness in traditional DAC models. Experimental evaluations confirmed ICFS’s effectiveness in restricting unauthorised access while maintaining functional compatibility with diverse applications, including text editors, browsers, and synchronisation tools. However, the system’s reliance on process-level identity checks revealed limitations in environments involving interpreted languages, containerised applications, and desktop portals. For instance, Flatpak sandboxes and the \verb|xdg-desktop-portal| daemon obscured process origins, undermining the granularity of access control. Similarly, shell scripting workflows faced usability challenges due to frequent permission prompts, highlighting tensions between security enforcement and practical usability.
+
+Performance benchmarks indicated a measurable overhead in filesystem operations. Yet, real-world usage scenarios showed negligible impact on application responsiveness, suggesting that the trade-off between security and performance is acceptable for typical user workflows. Security limitations, such as the potential for GUI automation tools to bypass access controls on X11 systems, underscore the need for deeper integration with sandboxing technologies and stricter isolation protocols in graphical environments.
+
+Future refinements to ICFS should focus on three key areas: enhancing interoperability with containerisation frameworks to preserve process context within sandboxes, developing session-based permission models to streamline shell script execution, and implementing robust mechanisms to audit and modify stored permissions. Additionally, mitigating risks associated with GUI interaction vulnerabilities will require collaboration with desktop environment developers to enforce stricter access controls for automation tools.
+
+In conclusion, ICFS represents a significant step toward simplifying advanced access control mechanisms by aligning security enforcement with user intuition. While its current iteration exposes inherent challenges in balancing dynamic policy enforcement with system complexity, the framework provides a foundational model for future innovations in user-driven cybersecurity solutions. By addressing the outlined limitations, subsequent development could further bridge the divide between academic security paradigms and practical, user-friendly implementation.

evaluation.tex

@@ -1,60 +1,110 @@
-\chapter{Evaluation}
+\chapter{Results}
 \label{eval}
 
-\todo[inline, caption={Complete Evaluation}, author={\textbf{Draft note}}]{This chapter is \emph{very} incomplete, and only contains a brief and informal talk about the issues I am facing right now. This is not the actual thesis-worthy text. All issues discussed were relevant as of 11.04.2025} 
+We tried to assess the quality of ICFS by the following metrics:
 
-In this chapter presents the method of evaluating the solution is presented, and the found qualities of the solution are discussed.
-
-Specifically will include:
 \begin{itemize}
-	\item ,,Does the solution actually solve the problem?''
-	\item Interoperability with other software: does using this fs break other programs, like whether it interferes with programs using auxiliary files, usability of terminal programs (\verb|grep| is a particularly nasty one for this specific project).
-	\item Performance and overhead.
-	\item Security considerations.
+	\item Usability : Does the interactive model reduce configuration burden while maintaining user control?
+	\item Security : Does ICFS effectively mitigate unauthorised access by untrusted processes?
+	\item Performance : What is the overhead introduced by ICFS compared to native filesystem operations?
 \end{itemize}
 
-\section{Interoperability}
+\section{Test Environment}
 
-\say{does using this fs break other programs?}
-\newline
+Performance and usability evaluations were conducted on an HP Pavilion Laptop 15-cc563st equipped with an Intel\textregistered\ Core\texttrademark\ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND M.2 SATA SSD (250GB), and 12 GB of DDR4 RAM. The system ran Fedora Linux 42 (Workstation Edition) with kernel version 6.14.5-300.fc42.x86\_64 and GNOME 48 under the Wayland session, and a btrfs-formatted disk. For additional compatibility testing, a KVM virtual machine hosted on the same hardware emulated a Debian GNU/Linux 12 (bookworm) environment with kernel 6.1.0-27-amd64, ext4 filesystem, GNOME 43.9, and the X11 windowing system. The virtual machine had 2 CPU cores and 2 GB of RAM.
 
-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).
+To simulate real-world usage, ICFS was mounted to a directory pre-populated with files, and interactions were tested across eight widely used applications:
 
-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
-
-\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.
-
-\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.
-
-As for regular terminal programs, I see these possible solutions:
 \begin{itemize}
-	\item Use SID and TTY to identify a shell session (like \verb|sudo| does).
+	\item {\TeX}studio.
+	\item Programming IDE/text editor (Neovim).
+	\item Markdown editor (Apostrophe).
+	\item A web browser (Mozilla Firefox).
+	\item File manager (GNOME Files, also known as Nautilus).
+	\item File synchronisation software (Syncthing).
+	\item Standard command line core utilities (e.g. \verb|ls|, \verb|cd|, \verb|grep|, ...).
 \end{itemize}
 
+These tools were selected for their prevalence and diverse filesystem interaction patterns. Except for Syncthing, Apostrophe (distributed via Flatpak containers) and Firefox (Flatpak and native versions), all applications were installed as native packages.
+
+\section{Usability}
+
+Testing revealed that most applications interacted smoothly with ICFS. 
+
+Since Syncthing only synchronises contents of selected directories, it was enough to give it permission to access those directories. Single access dialogue had to be displayed per each synchronised folder to achieve this.
+
+Apostrophe, TeXstudio and Neovim required a single permission prompt when opening existing projects, with no further interruptions. Since these programs are designed to work with multiple files contained in the same folder, it made sense to expand their permission scope to this folder.
+
+GNOME Files (Nautilus) exhibited unexpected behaviour. While functional without access permissions, its thumbnail generation process triggered repeated prompts. The file manager employs an external utility, gdk-pixbuf-thumbnailer, to create previews of files such as images. 
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.6\linewidth]{./images/picture-preview-nautilus.png}
+	\caption{Example of a picture mini-preview: image on the left is the scaled-down version of the actual image stored in the file.}
+\end{figure}
+
+Each preview required individual authorisation because the thumbnailer operates per-file, invalidating temporary folder permissions after each new image access. A pragmatic solution involves granting permanent access to the thumbnailer for specific directories -- a trade-off between convenience and security.
+
+Firefox interactions were limited to file downloads and uploads, which utilise system-level file selection dialogues provided by \verb|xdg-desktop-portal| service, and managed by the system file manager.
+
+\begin{figure}[H]
+	\centering
+	\includegraphics[width=0.6\linewidth]{./images/file-selection-dialogue.png}
+	\caption{File selection dialogue in Firefox.}
+\end{figure}
+
+Hence, it inherited all the usability issues Nautilus had. This dependency also introduced security implications discussed in the following section.\footnote{Only the Flatpak version of Firefox was affected.}
+
+Impact on shell scripting and command line tools' usability was significant. Since each shell command spawns a new process, users must grant permissions for every command individually.\footnote{Permanent permissions for core shell utilities are discouraged, as they expose the filesystem to unrestricted access via these tools.} A partial mitigation involved redirection operators (\verb|>|, \verb|>>|), which force the shell interpreter to handle file operations, allowing child processes to inherit permissions. However, this approach breaks compatibility with existing scripts. This limitation was anticipated, and potential solutions are discussed in \autoref{eval:future}.
+
+\section{Security}
+\label{eval:sec}
+
+The analysis of ICFS’s security profile reveals a significant reduction in security risks compared to traditional discretionary access control (DAC) models. As shown by our testing results, users can effectively define and restrict access to only the minimal needed set of files for programs to function. For example, users can define access control policies for Syncthing, Apostrophe, TeXstudio and Neovim in a way that only necessary access permissions were granted to programs. This curtails overprivileged processes and alerts users to unauthorised access attempts.
+
+But while ICFS represents a significant improvement over traditional access control systems in single-user environments, its design contains notable limitations.
+
+ICFS theoretically allows users to control every filesystem access operation, but the system's security depends heavily on the user's ability to interpret and respond to access requests. Despite efforts to make the interface accessible, the system generates prompts that may confuse average users. For example, access attempts by Apostrophe were displayed as actions by \verb|/usr/bin/python3.12|. This occurs because Apostrophe is written in Python, an interpreted language: all Python programs execute under the Python interpreter, causing dialogues to display the interpreter path rather than the application name. This limitation stems from ICFS's permission system, which tracks processes at the executable level. Users must understand this behaviour to avoid inadvertently granting interpreters permanent access to files, which would expose them to all scripts executed by the interpreter.
+
+Another challenge arises with Flatpak-packaged applications, which often obscure filesystem paths within their sandboxes. For instance, Syncthing's relocated executable path invalidated \verb|/proc/pid/exe|, the mechanism ICFS uses to resolve process identities via the \verb|readlink| system call. Current implementations rely on unvalidated paths returned by \verb|readlink|, leaving the system vulnerable to attacks where malicious processes mask their identity by manipulating sandboxed paths.
+
+A functional limitation arises with the \verb|xdg-desktop-portal| daemon, which centralises file-chooser interfaces across desktop environments to streamline user interactions. By design, this daemon handles file operations on behalf of requesting processes via D-Bus, acting as an intermediary that abstracts filesystem access. While this improves compatibility and user experience, it introduces a challenge for ICFS: the daemon obscures the identity of the originating process, making it difficult to enforce granular access control tied to specific applications.
+
+For example, files created or accessed through \verb|xdg-desktop-portal| inherit permissions based on the daemon itself rather than the requesting application. This creates a trade-off between usability and precision in access control. To somewhat mitigate unintended access, the \verb|--no-grant-on-create| flag disables automatic permission grants during file creation.\footnote{That is, the file creation operation will still be completed, but the requested process will gain no permissions to access the file next time.}
+
+However, the daemon retains user-driven file selection via graphical interfaces, maintaining safety equivalent to ICFS's core model (as both depend on GUI interactions remaining inaccessible to untrusted processes). This highlights a broader design constraint: similar trade-offs may exist when integrating with existing or ecosystem-wide services that centralise filesystem access.
+
+\subsection{Consequences of Unrestricted File Creation}
+\label{eval:sec:create}
+
+While it is safe to assume that processes do not have a way to access any data by creating files, that does not mean that other processes will remain unaffected.
+
+Unrestricted file creation enables attackers to manipulate application behaviour by generating configuration files in critical directories. For instance, a malicious process might create a \verb|.git| directory within a legitimate repository, causing git push to transmit data to a rogue server. This risk highlights how seemingly innocuous file creation privileges can escalate into systemic vulnerabilities.
+
+\subsection{Safety of Graphical Interfaces}
+
+While ICFS's access control system deters unprepared attackers, programmatic GUI interaction by an informed attacker poses a valid attack vector. ICFS relies on the assumption that GUI interactions are inaccessible to unprivileged processes; otherwise, an attacker could programmatically grant themselves permissions.
+
+On X11 systems, tools like xdotool \cite{XDOTOOL} enable unprivileged processes to simulate keystrokes and interact with windows, as verified in our Debian testing environment. In contrast, Wayland's security model restricts such interactions: xdotool and its Wayland equivalent, ydotool \cite{YDOTOOL}, cannot interfere with windows without explicit user permission via GNOME's graphical dialogues or superuser configuration.
+
+Theoretical risks remain via AT-SPI accessibility protocols, which could potentially interact with access dialogues. As a preventive measure, ICFS disables all accessibility features in access dialogues. However, this issue was not fully investigated within the scope of this thesis. Further research is needed to identify and address other potential attack vectors through desktop environment interfaces.
+
 \section{Performance}
 
-Performance of ICFS is terrible. Unfortunately, I was unable to make \verb|perf| work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck.
+Performance testing revealed a substantial impact on filesystem operations. A bash script\footnote{Filesystem stress test code can be found in the source code of ICFS, as a part of the general testing script.} opening large volumes of files in parallel ran in 0.714s on bare btrfs, 16.189s with temporary ICFS permissions, and 33.409s with permanent permissions. While ICFS access control layer likely affects other operations, these were not tested as they fall outside its scope.
 
-A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems. 
+Despite these synthetic benchmarks, real-world usability remained unaffected. Applications with intensive filesystem usage, such as Syncthing, experienced no critical slowdowns.
 
-But a lot can also be improved. For example, 
+\section{Future Work}
+\label{eval:future}
 
-\begin{itemize}
-	\item sqlite queries can be pre-``compiled''
-	\item (I think) more paralellism can be achieved.
-\end{itemize}
+Current version of ICFS lacks a way to edit permissions once they were granted. A solution would be to develop a simple tool that would communicate with ICFS daemon through a UNIX domain socket owned by a special user, and be able to open and edit the permanent permissions database via sqlite3 library. 
 
+Likewise, ICFS currently misses certain quality-of-life features, that might ease user decision-making process, such as in-dialogue filename validity checks and more verbose error messages. As a program that focuses on user interaction, ICFS would greatly benefit from such improvements.
 
-\section{Limitations}
-\label{eval:limit}
+A critical area for future refinement lies in addressing vulnerabilities stemming from programmatic interactions with graphical interfaces. ICFS currently assumes that GUI interactions remain inaccessible to unprivileged processes, yet this premise is challenged by tools like xdotool (on X11 systems), which can simulate keystrokes and manipulate windows without user consent. While Wayland's stricter isolation policies mitigate this risk -- requiring explicit user approval via GNOME dialogues or superuser privileges for tools like ydotool -- other exploits might be available to attackers, that were left unexplored in this thesis.
+
+Security limitations demand deeper integration with sandboxing frameworks. The reliance of ICFS on process-level identity introduces challenges when interacting with containerised applications, which obscure the original requesting process. Future work could explore deeper integration with such services to propagate context-aware permissions. For example, ICFS might integrate with Flatpak permission system to coordinate access control, possibly even set Flatpak sandbox permissions via graphical access dialogues (which Flatpak currently lacks).
+
+The current design's requirement for per-process permission grants creates friction for shell scripting, where new processes are frequently spawned. A potential solution involves implementing a session-based model, allowing the user to grant permissions to all processes with matching session ID (which typically corresponds to a single shell instance or script). This approach would preserve security while maintaining compatibility with existing scripts.
 
-It can only be used in a single-user environment.

implementation.tex

@@ -1,29 +1,71 @@
 \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, the architectural strategies employed to mitigate unauthorised filesystem access, methods for managing process-specific permissions, and the implementation of access dialogues.
 
-\section{FUSE framework}
+\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 behaviour. 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 \cite{LIBFUSE}. It initialises 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 specialised 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}
+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.
 
-\todo[inline, author={\textbf{Draft note}}]{Write how the source directory is protected}
+\section{Permission Tables}
 
-\section{Permission tables}
+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.
 
-\todo[inline, author={\textbf{Draft note}}]{Write how permission tables scheme was chosen}
+To pass permissions to child processes, both tables use procfs. When a permission check for the requesting process yields no results, recursive checks are performed on parent processes by traversing the process tree.
 
-\subsection{Temporary permissions}
+\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:
 
-\subsection{Permanent permissions}
+\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}
 
-\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.}
+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, 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 by accident, but also attempt to request a specific PID \cite{SOSETPID}. 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 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.
+
+One disadvantage this data structure, is that there isn't any inherent mechanism to remove entries that are no longer valid (e.g. permissions of a process that is already finished).
+
+Unfortunately, we haven't found an efficient way to remove expired entries in the temporary permission table. On Linux, a process can't be notified of other processes' end unless they are child processes or the tracking process is being run with superuser permissions \cite{SOPROCNOTIF}. Hence, we had to resort to cleaning out expired entries using the garbage collection technique: an independent thread periodically checks validity of every entry in the table. If an entry is invalid, it is erased.
+
+\subsection{Permanent Permissions}
+\label{impl:perm}
+
+Since permanent permissions are granted to all processes' with the same executable, only it's filename is needed for identification. Since the permissions have to persist after filesystem restart, the table needs to be stored on the disk. Hence, we chose SQLite \cite{SQLITE} as the backend for the permanent permissions table. It is well-tested and lightweight, making it an ideal choice for a program like ICFS.
+
+Due to specifics of relational databases, the permissions are stored as a relation  \allowbreak$(executable, filename, type)$, where $executable$ is the filename of the executable, $filename$ is a filename of the file that the permission targets and $type$ is a boolean value indicating whether the permission allows or prohibits access to the target file.
+
+The database is stored in a file on the disk that the user chooses during startup. The database file is protected from outside access using standard POSIX permissions: during installation, a special user is created for ICFS, the owner UID of the executable is set to the UID of the new user, and the setuid bit is set, to allow other users to launch ICFS as a special user. On startup, database file is created as the special user, and the access mode is set to prohibit access by any other user. After the database is opened, UID of ICFS process (effective UID) is switched to the UID of the user (real UID) that originally started it using the \verb|setuid| system call. The database remains open for the rest of the runtime of ICFS.
+
+Unfortunately, in the current version of ICFS there is no way to edit the permanent permission table. We discuss this limitation in more detail in \autoref{eval:future}.
+
+\section{Access dialogues}
+
+Access dialogues are implemented as a separate program, that the FUSE daemon spawns using the \verb|popen| function, provided by the standard C library. In the arguments, daemon specifies (in this order):
+
+\begin{itemize}
+	\item The PID of the requesting process.
+	\item Path to the process's executable.
+	\item ICFS's mountpoint.
+	\item Name of the file the process is attempting to access.
+\end{itemize}
+
+After user interaction, the dialogue terminates with an exit code indicating the decision and outputs the relevant filename to standard output. The daemon validates the filename’s existence and relevance to the original request.
+
+For example, if a process requests access to \verb|~/Documents/book.pdf|, but the dialogue specifies a nonexistent file or an unrelated file like \verb|~/Documents/other.txt|, the dialogue reappears. Currently, input validation occurs solely within the FUSE daemon, not the dialogue itself. Integrating real-time feedback on input validity into the dialogue interface could enhance usability, as noted in \autoref{eval:future}.
+
+The access dialogue program is written in C and utilises GTK4 \cite{GTK} and libadwaita \cite{ADW} libraries for its graphical interface.

intro.tex

@@ -3,20 +3,6 @@
 \addcontentsline{toc}{chapter}{Introduction}
 \markboth{Introduction}{Introduction}
 
-\iffalse
-
-The introduction contains:
-
-\begin{itemize}
-	\item the state of things
-	\item The problem
-	\item Existing solutions and why they don't work
-	\item our approach
-	\item the layout of the thesis
-\end{itemize}
-
-\fi
-
 In modern operating systems, access control mechanisms are fundamental to ensuring the confidentiality, integrity, and availability of system resources. These mechanisms dictate how users and processes interact with system objects such as files, directories, and devices. However, traditional access control models, such as the discretionary access control (DAC) employed by Linux and other Unix-like systems, operate under the assumption that all processes running under the same user account should have the same level of access to system resources. While this simplifies user management and permissions, it can introduce significant security risks.
 
 The problem arises when a process or application running under a user's account becomes compromised. In such cases, the malicious code or exploit can leverage the user's existing permissions to access or modify sensitive data, potentially leading to data breaches or other security incidents. This fundamental limitation of traditional access control mechanisms underscores the need for a more granular and dynamic approach to filesystem access control.
@@ -25,4 +11,4 @@ Over the years, various mandatory access control (MAC) mechanisms, such as SELin
 
 In this thesis we introduce our approach to filesystem access control that empowers users to make real-time decisions about which processes or applications should have access to specific filesystem objects. By integrating an interactive decision-making layer into the filesystem, this solution aims to bridge the gap between the security benefits of MAC mechanisms and the simplicity required for widespread adoption. The proposed system delegates access control decisions to the user, enabling them to grant or deny access to individual processes or applications on a per-object basis. This approach not only enhances security but also maintains the flexibility and usability that are critical for user-oriented systems.
 
-The rest of this thesis is organised as follows: \Cref{access} and \cref{current} provides a review of existing access control mechanisms and their limitations. \Cref{icfs} outlines the design objectives, architecture, and the interactive component of the proposed file system layer. \Cref{impl} describes the implementation process, including the tools and techniques used to develop the system. Finally, in \cref{eval} we present experimental results, evaluate the performance, security benefits and limitations of the proposed solution, and discuss the potential for further development.
+The rest of this thesis is organised as follows: \Cref{access} and \cref{current} provide a review of existing access control mechanisms and their limitations. \Cref{icfs} outlines the design objectives, and the interactive component of the proposed filesystem layer. \Cref{impl} describes the implementation process, including the tools and techniques used to develop the system. Finally, in \cref{eval} we present experimental results, evaluate the performance, security benefits and limitations of the proposed solution, and discuss the potential for further development.

literatura.bib

@@ -67,24 +67,116 @@
 @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}
+}
+
+@online{SOPROCNOTIF,
+	title = {c++ - How to get notified when a process ends under linux? - Stack Overflow},
+	year = {2016},
+	url = {https://stackoverflow.com/questions/34800568/how-to-get-notified-when-a-process-ends-under-linux}
+}
+
+@online{SOSETPID,
+	title = {How to set process ID in Linux for a specific program - Stack Overflow},
+	year = {2014},
+	url = {https://stackoverflow.com/questions/18122592/how-to-set-process-id-in-linux-for-a-specific-program}
+}
+
+@online{GTK,
+	title = {The GTK Project - A free and open-source cross-platform widget toolkit},
+	year = {2025},
+	organization  = {GTK Team},
+	version={4.18.4},
+	url = {https://gtk.org/}
+}
+
+@online{ADW,
+	title = {Adwaita},
+	year = {2025},
+	organization  = {The GNOME Project},
+	version={1.7.2},
+	url = {https://gnome.pages.gitlab.gnome.org/libadwaita/}
+}
+
+@online{SQLITE, 
+	title={{SQLite}},
+	url={https://www.sqlite.org/index.html},
+	version={3.47.2},
+	year={2024},
+	author={Hipp, Richard D}
+}
+
+@online{LIBFUSE,
+	title={{libfuse}},
+	url={https://github.com/libfuse/libfuse},
+	version={3.17.2},
+	year={2025},
+}
+
+@online{XDOTOOL,
+	title={{jordansissel/xdotool: fake keyboard/mouse input, window management, and more}},
+	url={https://github.com/jordansissel/xdotool},
+	version={3.20211022.1},
+	year={2021},
+}
+
+@online{YDOTOOL,
+	title={{ReimuNotMoe/ydotool: Generic command-line automation tool (no X!)}},
+	url={https://github.com/ReimuNotMoe/ydotool},
+	version={1.0.4},
+	year={2023},
+}
+
+@software{tange_2024_14550073,
+	author       = {Tange, Ole},
+	title        = {GNU Parallel 20241222 ('Bashar')},
+	month        = Dec,
+	year         = 2024,
+	note         = {{GNU Parallel is a general parallelizer to run
+	multiple serial command line programs in parallel
+	without changing them.}},
+	publisher    = {Zenodo},
+	doi          = {10.5281/zenodo.14550073},
+	url          = {https://doi.org/10.5281/zenodo.14550073}
+}

main-en.tex

@@ -9,9 +9,15 @@
 %nice code
 \usepackage{minted}
 %todos
-\usepackage[textwidth=20mm]{todonotes}
+%\usepackage[textwidth=20mm]{todonotes}
 %quotes
-\usepackage{dirtytalk}
+%\usepackage{dirtytalk}
+%fancy bibliography
+\usepackage[
+backend=biber,
+style=ieee,
+]{biblatex}
+\addbibresource{literatura.bib}
 
 
 
@@ -45,22 +51,29 @@
 \usepackage[hidelinks,breaklinks]{hyperref}
 %fancy references
 \usepackage{cleveref} 
+%strikethorugh
+\usepackage[normalem]{ulem}
+
+\usepackage{subcaption}
+
+% Images
+\graphicspath{ {./images/} }
 
 % -------------------
 % --- REMOVE BEFORE PUBLISHING
 % -------------------
 % Big "draft" watermark on the side.
-\usepackage{lipsum}
-\usepackage{background}
-\backgroundsetup{
-	position=current page.east,
-	angle=-90,
-	nodeanchor=east,
-	vshift=-5mm,
-	opacity=1,
-	scale=3,
-	contents=Draft
-}
+%\usepackage{lipsum}
+%\usepackage{background}
+%\backgroundsetup{
+%	position=current page.east,
+%	angle=-90,
+%	nodeanchor=east,
+%	vshift=-5mm,
+%	opacity=1,
+%	scale=3,
+%	contents=Draft
+%}
 
 
 % -------------------
@@ -267,7 +280,7 @@ or deny access to a filesystem object by a specific process to the user.
 \newpage 
 
 \listoffigures
-\listoftables
+%\listoftables
 
 % ---  Koniec Zoznamov
 
@@ -278,7 +291,7 @@ or deny access to a filesystem object by a specific process to the user.
 % --- REMOVE BEFORE PUBLISHING
 % -------------------
 % Todo list
-\listoftodos
+%\listoftodos
 
 \input intro.tex
 
@@ -302,6 +315,8 @@ or deny access to a filesystem object by a specific process to the user.
 % --- Bibliografia
 % -------------------
 
+% GNU parallel in the testing scripts.
+\nocite{tange_2024_14550073}
 
 \newpage	
 
@@ -310,8 +325,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}
@@ -337,7 +352,7 @@ or deny access to a filesystem object by a specific process to the user.
 %Nepovinná časť prílohy obsahuje materiály, ktoré neboli zaradené priamo  do textu. Každá príloha sa začína na novej strane.
 %Zoznam príloh je súčasťou obsahu.
 %
-%\input appendixA.tex
+\input appendixA.tex
 
 %\input appendixB.tex
 

motivation.tex

@@ -1,35 +1,36 @@
 
 
-\chapter{Current solutions, and why they won't suffice}
+\chapter{Current Solutions, and Why They Won't Suffice}
 \label{current}
 
-\section{MAC mechanisms}
+\section{MAC Mechanisms}
 
-Many Linux OS ship with additional Mandatory Access Control (MAC) mechanisms (e.g.\ AppArmor, SELinux) that allow to restrict the usage of file system objects by specific programs.\todo[inline, author={\textbf{Draft note}}]{Explain how exactly can they do that? (It seems irrelevant to the overall topic)} 
+Many Linux OS ship with additional Mandatory Access Control (MAC) mechanisms (e.g.\ AppArmor, SELinux) that allow to restrict the usage of filesystem objects by specific programs.
 
 Unfortunately, these mechanisms require a considerable amount of knowledge and effort for the user to manage them, which makes them infeasible for most single-user environments.
 
 
 
 \section{FGACFS}
+\label{current:FGACFS}
 
 In Lovyagin et. al. 2020 \cite{FGACFS} authors propose and implement a so called FGACFS filesystem that extends traditional UNIX access control policies with far more sophisticated and granular system. This also includes the ability to restrict access on per-program basis. However, due to the sheer variety of options and configurable parameters, this approach still falls short when it comes to ease of use and user-friendliness.
 
-Additionally, all the above solutions share a significant drawback: they necessitate user intervention to secure files, even when those files are never accessed. For instance, if access to a file system object is denied (allowed) for all programs by default and only allowed (denied) for specific ones, granting (revoking) access for new programs requires users to modify access permissions proactively.
+Additionally, FGACFS and MAC mechanisms described above share a significant drawback: they necessitate user intervention to secure files, even when those files are never accessed. For instance, if access to a filesystem object is denied (allowed) for all programs by default and only allowed (denied) for specific ones, granting (revoking) access for new programs requires users to modify access permissions proactively.
 
 While some solutions offer automatic inheritance or assignment of rules and access control policies, they still need extensive manual configuration. Even if inheriting all access permissions from a default value were practical, installing new programs would always necessitate updating rules to adhere to the principle of least privilege.
 
-Another problem of these solutions, is that their policies are granted forever and the user is never informed about the actual usage of those permissions, which makes them more vulnerable to attacks by proxy. For example, if the program \verb|cat| is allowed to read contents of the file \verb|~/secrets/text.txt|, malicious program may execute \verb|cat ~/secrets/text.txt > ~/stolen-text.txt| command at any time, without any warning and regardless of whether the malicious program has access to \verb|~/secrets/text.txt| or \verb|~/stolen-text.txt|. If the user only granted read permissions to \verb|cat| when they are actually using the program themselves, such attack could likely be avoided.
+Another problem of these solutions, is that their policies are granted forever and the user is never informed about the actual usage of those permissions, which makes them more vulnerable to attacks by proxy. For example, if the program \verb|cat| is allowed to read contents of the file \verb|~/secrets/text.txt|, malicious program may execute \verb|cat ~/secrets/text.txt > ~/stolen-text.txt| command at any time, without any warning and regardless of whether the malicious program has access to \mintinline[breaklines,breakafter=/]{latex}{~/secrets/text.txt} or \verb|~/stolen-text.txt|. If the user only granted read permissions to \verb|cat| when they are actually using the program themselves, such attack could likely be avoided.
 
 \section{Containerisation}
 
-Another solution to consider, is using containerised software distribution, like Flatpak\cite{FLATPAK}, Snapcraft\cite{SNAP} or AppImage\cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but, most importantly, file system objects. 
+Another solution to consider, is using containerised software distribution, like Flatpak \cite{FLATPAK}, Snapcraft \cite{SNAP} or AppImage \cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but -- most importantly -- filesystem objects. 
 
 However, because the developer of the distributed software is responsible for defining the permissions that his own program needs, it often leads to programs having excessive privileges after installation\footnote{It is important to mention, that although this flaw remains unmitigated, the analysis made by Dunlap et al. 2022 \cite{DunlapMAC} shows that most package maintainers actively attempt to define least-privilege application policies.} without any notification of the user.
 
 Additionally, it is a responsibility of the software developer to choose the distribution method, and despite containerised software getting more and more popular, there are still plenty of programs that can only be installed using traditional methods, that do not offer any mechanisms for restricting filesystem access. 
 
-Furthermore, some software is impractical to sandbox. For example, because of the FlatPak's design, CLI software has to be run with \verb|flatpak run| command and has to use often long and hard-to-remember package names, which may appear rather cumbersome for most users.
+Furthermore, some software is impractical to sandbox. For example, because of the Flatpak's design, CLI software has to be run with \verb|flatpak run| command and has to use often long and hard-to-remember package names, which may appear rather cumbersome for most users.
 
 \section{Android}
 
@@ -37,24 +38,30 @@ 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}
+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}
 
 Unfortunately, Android access control system is specific to Android. Also, it inherits the already mentioned drawbacks of containerisation, and only works through special API, thus requiring the software to be redesigned to work with such an access control system.
 
 \section{Ranacco}
 
 Finally, in McIntosh et al. 2021 \cite{MCINTOSH} authors propose and implement software called \emph{Ranacco}, which attempts to analyse various system environmental factors (e.g. latest mouse and keyboard activity) and filesystem operations to detect potentially malicious actions made by processes, in which case it delegates access control decision to the user. This approach avoids the shortcomings of other possible solutions, while remaining easy-to-use. Although this system is more advanced than the one we propose in this thesis, not only is it exclusive to Windows, but it also remains unavailable for the general public.
-\iffalse
 
-Overall, there appears to be little research on systems that actively involve users in access control decision-making. Most of the literature on alternative access control systems either focuses on passive policy regulation intended for large multi-user systems, which has the same drawbacks as the already mentioned default Linux access control systems, or on systematic analysis of access control vulnerabilities (Parkinson et al.) \cite{BIGSURSTAT}. 
+\section{Requirements for the Solution}
 
-\fi
-
-\section{Requirements for the solution}
-
-\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}
+%\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}
 
 The key issues with existent solutions, that our the system proposed in this thesis will try to address are as follows:
 \begin{itemize}
@@ -64,30 +71,9 @@ The key issues with existent solutions, that our the system proposed in this the
 	
 	\item Most solutions require passive action from the user besides initial installation (e.g. you have to reconfigure policies all the time). This adds further inconvenience to using such systems.
 	
-\iffalse
-	\item Some solutions run inside the kernel. This makes bugs particularly dangerous, and complicates the installation process.
-\fi
-	
 	\item Most solutions grant permissions forever, which significantly increases attack surface. Specifically, this opens up possibilities for attacks by proxy.
 	
 	\item Majority of solutions focus on preventing unwanted access by other users, which makes it unsuitable for single-user environments.
 	
 	\item Solutions are either overly complex and not user-friendly, or too simplistic to provide adequate granularity of permissions. This either leads to slower adoption of such systems, or makes them insufficient at protecting user data.
 \end{itemize}
-
-\iffalse
-
-The key differences of the software proposed in this article to those already mentioned and researched (to the best of our knowledge) are as follows:
-\begin{itemize}
-	\item Unlike other approaches, proposed software assumes all processes to be malicious until proven (confirmed by the user to be) safe. All of the access control permissions are granted as-needed, not predefined, inferred or assumed.
-	\item Proposed software provides potentially high (e.g. can be granted on per-object basis), and flexible granularity of permissions.
-	\item Proposed software is intuitive and simple-to-use. It's usage does not require prior knowledge of advanced access control policies.
-	\item Proposed software runs entirely in user space. This reduces possibilities for system-breaking bugs, and make installation trivially simple.
-	\item Proposed software does not require programs to use any special API or be packaged in any special way. All programs will have to respect policies enforced by our software.
-	\item Proposed software does not require any passive action from the user besides initial installation (e.g. you don't have to reconfigure policies all the time).
-	\item Proposed software grants permissions temporarily, which reduces attack surface compared to other methods.
-\end{itemize}
-
-\fi
-
-