Final edits

appendixA.tex

@@ -1,4 +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. 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.
+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

@@ -52,7 +52,7 @@ The dialogue contains three functional elements:
 \begin{itemize}
 	\item Access Grant Buttons.
 	\begin{itemize}
-		\item Yes Button : Grants temporary access to the requested file to the requesting process only. If the user selects this option, the process is allowed to proceed with the requested access (e.g., read, write).
+		\item 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.
@@ -70,7 +70,7 @@ This model addresses five key limitations of traditional systems:
 
 \begin{itemize}
 	\item Reactive Configuration: No upfront setup required; permissions emerge organically.
-	\item Temporary Permissions: Users may limit access to a single instance.
+	\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}
 
@@ -84,16 +84,14 @@ To reduce friction, ICFS needs to keep the number of dialogues to minimum. This
 
 When ICFS is initially started, no user decisions are known, and thus no processes have access to protected files. Each new access attempt triggers a privilege escalation request via the access dialogue.
 
-Applying this rule strictly to all filesystem objects -- including directories and symbolic links -- with intelligent user decisions, would perfectly adhere to the principle of least privilege.
-
-However, such strictness would render ICFS excessively cumbersome to use. To mitigate this, the rule has been relaxed to compromise user data as little as possible.
+Applying this rule strictly to all filesystem objects -- including directories and symbolic links -- with intelligent user decisions, would perfectly adhere to the principle of least privilege. However, such strictness would render ICFS excessively cumbersome to use. To mitigate this, the rule has been relaxed to compromise user data as little as possible.
 
 Firstly, Unlike POSIX, ICFS does not restrict directory visibility. While this exposes file structures, directory names rarely contain sensitive data.
 
 Second, processes are permitted to create files without restriction. This decision is based on the observation that many programs create auxiliary and temporary files. For instance, the pdfLaTeX compiler creates 21 files in the source directory for this thesis, only 10 of which are human-editable; the remaining files are intermediary output of the compiler. Requiring the user to grant permissions for all these files would more than double the decision-making burden.
 
-While this approach increases the potential for malicious processes to disrupt other processes, the risk is considered lower than the burden of constantly prompted permission requests. We discuss these limitations in \autoref{eval:sec}.
+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}.
 
 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. We discuss potential threats that relate to this rule in \autoref{eval:sec}.
+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

@@ -6,7 +6,7 @@ This thesis introduced the Interactively Controlled File System (ICFS), a novel
 
 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.
+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.
 

evaluation.tex

@@ -4,14 +4,14 @@
 We tried to assess the quality of ICFS by the following metrics:
 
 \begin{itemize}
-	\item Security : Does ICFS effectively mitigate unauthorized access by untrusted processes?
 	\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® 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.
+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:
 
@@ -29,8 +29,11 @@ These tools were selected for their prevalence and diverse filesystem interactio
 
 \section{Usability}
 
-Testing revealed that most applications interacted smoothly with ICFS. Command line utilities, Syncthing, Apostrophe, TeXstudio and Neovim required a single permission prompt when opening existing files, with no further interruptions for new file creation. Furthermore, they have only maintained access to files they actually needed to function.
+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. 
 
@@ -57,7 +60,9 @@ Impact on shell script usability was significant. Since each shell command spawn
 \section{Security}
 \label{eval:sec}
 
-While ICFS represents a significant improvement over traditional access control systems in single-user environments, its design contains notable limitations.
+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 behavior to avoid inadvertently granting interpreters permanent access to files, which would expose them to all scripts executed by the interpreter.
 
@@ -65,10 +70,17 @@ Another challenge arises with Flatpak-packaged applications, which often obscure
 
 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-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.
+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.\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.
@@ -79,7 +91,7 @@ Theoretical risks remain via AT-SPI accessibility protocols, which could potenti
 
 \section{Performance}
 
-Performance testing revealed a substantial impact on filesystem operations. A bash 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's access control layer likely affects other operations, these were not tested as they fall outside its scope.
+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.
 
@@ -88,11 +100,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.
+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 current reliance on resolving process identities via \verb|/proc/pid/exe| proves insufficient in containerised environments, where executable paths are visualised. 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 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

@@ -1,18 +1,18 @@
 \chapter{Implementation}
 \label{impl}
 
-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.
+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}
 \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.
+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 this API in C using the libfuse3 library \cite{LIBFUSE}. It initializes the FUSE daemon via the \verb|fuse_main()| function, which manages communication between the kernel and the FUSE application. Rather than directly overriding system calls, FUSE interacts with the kernel through \verb|/dev/fuse|, a specialized device file that translates filesystem requests into API method invocations using a dedicated protocol.
+ICFS 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 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}
 
@@ -32,13 +32,13 @@ To function, temporary permissions storage should contain all information needed
 
 The process is considered the same if and only if both characteristics match.
 
-At first, it might seem that factoring in start time is excessive. However, only using PID as the only identifying property of a process is problematic: PID is only unique among the currently running processes, not across the entire uptime of the system. Processes can not only acquire the PID of another, already finished process, but also attempt to request a specific PID. The start time is looked up in procfs by PID, which is provided by libfuse.
+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 of such a 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).
+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.
 
@@ -51,7 +51,7 @@ 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}.
+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}
 
@@ -64,10 +64,8 @@ Access dialogues are implemented as a separate program, that the FUSE daemon spa
 	\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 that this decision relates to in its standard output. Daemon then validates the filename correctness. 
+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.
 
-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.
+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}.
 
-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.
+The access dialogue program is written in C and utilises GTK4 \cite{GTK} and libadwaita \cite{ADW} libraries for its graphical interface.

intro.tex

@@ -5,7 +5,7 @@
 
 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 file system access control.
+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.
 
 Over the years, various mandatory access control (MAC) mechanisms, such as SELinux (Security-Enhanced Linux) and AppArmor have been developed to address these limitations. These systems enforce access control policies at a more granular level, often based on labels or rules defined by system administrators. While these mechanisms are effective in certain scenarios, they are generally complex to configure and require significant expertise to maintain. As a result, they are rarely adopted in common user-oriented environments, where simplicity and ease of use are paramount.
 

literatura.bib

@@ -117,6 +117,28 @@
 	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},
@@ -143,7 +165,7 @@
 	title={{ReimuNotMoe/ydotool: Generic command-line automation tool (no X!)}},
 	url={https://github.com/ReimuNotMoe/ydotool},
 	version={1.0.4},
-	year={2021},
+	year={2023},
 }
 
 @software{tange_2024_14550073,

main-en.tex

@@ -280,7 +280,7 @@ or deny access to a filesystem object by a specific process to the user.
 \newpage 
 
 \listoffigures
-\listoftables
+%\listoftables
 
 % ---  Koniec Zoznamov
 
@@ -315,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	
 

motivation.tex

@@ -12,24 +12,25 @@ Unfortunately, these mechanisms require a considerable amount of knowledge and e
 
 
 \section{FGACFS}
+\label{current:FGACFS}
 
 In Lovyagin et. al. 2020 \cite{FGACFS} authors propose and implement a so called FGACFS file system 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 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.
 
 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 -- file system 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 file system 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}