111 lines
13 KiB
TeX
111 lines
13 KiB
TeX
\chapter{Results}
|
||
\label{eval}
|
||
|
||
We tried to assess the quality of ICFS by the following metrics:
|
||
|
||
\begin{itemize}
|
||
\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{Test Environment}
|
||
|
||
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.
|
||
|
||
To simulate real-world usage, ICFS was mounted to a directory pre-populated with files, and interactions were tested across eight widely used applications:
|
||
|
||
\begin{itemize}
|
||
\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 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.
|
||
|
||
Despite these synthetic benchmarks, real-world usability remained unaffected. Applications with intensive filesystem usage, such as Syncthing, experienced no critical slowdowns.
|
||
|
||
\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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|