:)

accesscontrol.tex

@@ -27,7 +27,7 @@ Although this kind of access control solutions has been proven to be helpful in
 
 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.
 

appendixA.tex

@@ -0,0 +1,4 @@
+\chapter*{Appendix A: source code}
+\addcontentsline{toc}{chapter}{Príloha A}
+
+Source code of ICFS can be found on the CD attached to this thesis, and on the internet. It can be accessed on \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,16 +1,16 @@
 \chapter{Interactively Controlled File System}
 \label{icfs}
 
-This chapter presents the solution developed for this thesis, the Interactively Controlled File System (ICFS), a user-centric filesystem layer designed to enhance access control through real-time user input.
+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 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 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.
 
 Key Features:
 
 \begin{itemize}
-	\item User-Friendly Design: Requires no prior configuration or specialized knowledge. The intuitive interface eliminates complex terminology, enabling seamless interaction.
-	\item Dynamic Policy Enforcement: Permissions are established on-demand and stored for future reference, minimizing repetitive prompts.
-	\item Granular Control: Policies apply at the process-file level, with options to generalize rules for broader categories, reducing user fatigue.
+	\item 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}
 
@@ -26,7 +26,7 @@ icfs <FUSE arguments> [mounpoint] [permission database] <ICFS arguments>
 \label{icfs:usage:cmd}
 \end{figure}
 
-This mounts ICFS over the specified directory, enforcing access control for all subsequent interactions. While the name includes "File System," ICFS operates as a filesystem layer , intermediating between the physical filesystem (e.g., ext4) and user processes. It preserves the appearance of the original filesystem while enforcing its own access logic (implementation details in \autoref{impl:fuse}).
+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}
@@ -55,10 +55,10 @@ The dialogue contains three functional elements:
 		\item Yes Button : Grants temporary access to the requested file to the requesting process only. If the user selects this option, the process is allowed to proceed with the requested access (e.g., read, write).
 		\item No Button : Denies access to the file for the current process. The filesystem returns an error (e.g., EACCES) to the requesting process, mimicking standard permission denial behavior.
 	\end{itemize}
-	\item Permanent Permission Checkbox: A toggle labelled "Permanent" allows the user to persist the access decision beyond the current process.
+	\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``).
+	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}
 
@@ -78,7 +78,7 @@ The remaining two criteria are analysed in the next section.
 
 \section{Least Privilege vs. Usability}
 
-Balancing the principle of least privilege with usability posed the greatest design challenge. Strict enforcement -- prompting for every access attempt -- would minimize risk but overwhelm users.
+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.
 
 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.
 

conclusion.tex

@@ -4,7 +4,7 @@
 
 This thesis introduced the Interactively Controlled File System (ICFS), a novel approach to file system 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.
 
-The implementation of ICFS demonstrates that granular, context-aware access control can be achieved through a user-centric 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.
+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, particularly under heavy usage of that involves permission checking. 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.
 

evaluation.tex

@@ -9,7 +9,7 @@ We tried to assess the quality of ICFS by the following metrics:
 	\item Performance : What is the overhead introduced by ICFS compared to native filesystem operations?
 \end{itemize}
 
-\section{Test environment}
+\section{Test Environment}
 
 Performance and usability evaluations were conducted on an HP Pavilion Laptop 15-cc563st equipped with an Intel® Core™ 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.
 
@@ -69,7 +69,7 @@ For example, files created or accessed through \verb|xdg-desktop-portal| inherit
 
 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{Safety of graphical interfaces}
+\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.
 
@@ -83,7 +83,7 @@ Performance testing revealed a substantial impact on filesystem operations. A ba
 
 Despite these synthetic benchmarks, real-world usability remained unaffected. Applications with intensive filesystem usage, such as Syncthing, experienced no critical slowdowns.
 
-\section{Future work}
+\section{Future Work}
 \label{eval:future}
 
 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. 

implementation.tex

@@ -3,7 +3,7 @@
 
 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}
+\section{FUSE Framework}
 \label{impl:fuse}
 
 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.
@@ -12,15 +12,15 @@ ICFS implements this API in C using the libfuse3 library \cite{LIBFUSE}. It init
 
 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.
 
-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.
+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}
+\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.
 
 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}
 
 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:
@@ -42,7 +42,7 @@ One disadvantage of such a data structure, is that there isn't any inherent mech
 
 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}
+\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.

main-en.tex

@@ -9,9 +9,9 @@
 %nice code
 \usepackage{minted}
 %todos
-\usepackage[textwidth=20mm]{todonotes}
+%\usepackage[textwidth=20mm]{todonotes}
 %quotes
-\usepackage{dirtytalk}
+%\usepackage{dirtytalk}
 %fancy bibliography
 \usepackage[
 backend=biber,
@@ -63,17 +63,17 @@ style=ieee,
 % --- 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
+%}
 
 
 % -------------------
@@ -291,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
 
@@ -350,7 +350,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,9 +1,9 @@
 
 
-\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.
 
@@ -47,10 +47,10 @@ When an app need permission to access the shared storage (part of the filesystem
 		\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``}
+	\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.
 
@@ -58,7 +58,7 @@ Unfortunately, Android access control system is specific to Android. Also, it in
 
 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 file system 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.
 
-\section{Requirements for the solution}
+\section{Requirements for the Solution}
 
 %\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}