:)

approach.tex

@@ -59,7 +59,7 @@ The dialogue contains three functional elements:
 	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).
+	\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}
 
 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.

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 vulnerabilities in environments involving interpreted languages, containerised applications, and desktop portals. For instance, Flatpak sandboxes and the 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, 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.
 
 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

@@ -63,11 +63,11 @@ ICFS theoretically allows users to control every filesystem access operation, bu
 
 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 larger, unresolved issue involves the \verb|xdg-desktop-portal| daemon. To unify file-chooser interfaces across desktop environments, this background service handles file opening operations on behalf of requesting processes via D-Bus\footnote{D-Bus is an inter-process communication method on Linux.}. The open file descriptors are then passed to the requesting processes, allowing it to use the file normally. While simplifying file management, the daemon prevents ICFS from identifying the original requesting process, thereby undermining granular access control.
+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.
 
-A critical unresolved issue involves the \verb|xdg-desktop-portal| daemon, which centralises file-chooser interfaces across desktop environments. By handling file operations on behalf of requesting processes via D-Bus,\footnote{D-Bus is an inter-process communication mechanism in Linux.} the daemon obscures the original process, undermining ICFS's granular access control.
+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-perm-on-create| flag disables automatic permission grants during file creation. This ensures, that the user would always be informed about the files programs access through xdg-desktop-portal.
 
-Consequently, files created through \verb|xdg-desktop-portal| become accessible to any process using the daemon. To address this, the \verb|--no-perm-on-create| flag disables permission grants during file creation. However, \verb|xdg-desktop-portal| retains user-controlled file selection via graphical interfaces, ensuring safety\footnote{That is, safety equivalent to ICFS, since both of them depend on the inaccessibility of GUI interaction by foreign processes.} in this context. This highlights a broader concern: similar behaviours in other daemons may exist, even if undetected in our analysis.
+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}
 
@@ -88,9 +88,11 @@ Despite these synthetic benchmarks, real-world usability remained unaffected. Ap
 
 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 decsion-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 these 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 current reliance on resolving process identities via /proc/pid/exe proves insufficient in containerized environments, where executable paths are virtualized. 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).
+Security limitations demand deeper integration with sandboxing frameworks. The current reliance on resolving process identities via \verb|/proc/pid/exe| proves insufficient in containerized environments, where executable paths are virtualized. 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.
 

implementation.tex

@@ -52,3 +52,22 @@ Due to specifics of relational databases, the permissions are stored as a relati
 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 address 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 completes their interaction, the access dialogue finishes with exit code corresponding to the access control decision and writes filename this decision relates to in its standard output. Daemon then validates the filename correctness. 
+
+If the filename specified in the dialogue does not correspond to a real file, or modifying the process's access to the specified file won't resolve the original request, access dialogue is displayed again. For example, if the process requests access to a file \verb|~/Documents/book.pdf|, but in the dialogue they specify a nonexistent file, or \verb|~/Documents/other.txt| (which exists), the dialogue would be displayed again.
+
+In the current version, file substitution field correctness checks are not integrated in the access dialogue program, and are entirely delegated to the FUSE daemon. Giving user immediate feedback on input validity within access dialogues can potentially be a valuable usability improvement.
+
+The access dialogue program is written in C, and uses GTK4 and libadwaita libraries to provide a graphical interface.

intro.tex

@@ -11,4 +11,4 @@ Over the years, various mandatory access control (MAC) mechanisms, such as SELin
 
 In this thesis we introduce our approach to file system access control that empowers users to make real-time decisions about which processes or applications should have access to specific file system objects. By integrating an interactive decision-making layer into the file system, 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 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.