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

accesscontrol.tex

@@ -7,7 +7,7 @@ By default, UNIX-like operating systems only provide simplistic Discretionary Ac
 
 The policy used by traditional UNIX systems is based on the concepts of \textit{file owner}, \textit{group of a file}, and \textit{others}. For each file, the access rights for these three categories can be specified independently using a so-called access mode. The access mode is a bitmask which specifies whether the file owner, the group of the file, and others have read, write, or execute permissions.
 
-Each process has it's own \textit{Effective User ID} (EUID),  the user that the process is running on behalf of. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
+Each process has its own \textit{Effective User ID} (EUID),  the user that the process is running on behalf of. When a process tries to access a file, the kernel checks the access mode of the file, and grants or denies access based on the following rules:
 
 \begin{itemize}
 	\item If the process's effective user ID matches the file owner, the file owner's access mode is used.

conclusion.tex

@@ -2,7 +2,7 @@
 \addcontentsline{toc}{chapter}{Conclusion} % rucne pridanie do obsahu
 \markboth{Conclusion}{Conclusion} % vyriesenie hlaviciek
 
-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.
+This thesis introduced the Interactively Controlled File System (ICFS), a novel approach to filesystem access control designed to address the inherent limitations of traditional discretionary access control (DAC) mechanisms in Linux environments. By placing access control decisions directly in the hands of users through real-time graphical prompts, ICFS bridges the gap between coarse-grained flexibility of DAC and the rigid complexity of mandatory access control (MAC) frameworks. The system’s design prioritises usability without compromising security, enabling users to grant or deny process-specific permissions dynamically while maintaining backward compatibility with existing software workflows via the FUSE framework.
 
 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.
 

evaluation.tex

@@ -55,7 +55,7 @@ Firefox interactions were limited to file downloads and uploads, which utilise s
 
 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 script 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}.
+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}
@@ -64,13 +64,13 @@ The analysis of ICFS’s security profile reveals a significant reduction in sec
 
 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.
+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-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.}
+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.
 

intro.tex

@@ -9,6 +9,6 @@ The problem arises when a process or application running under a user's account
 
 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.
 
-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.
+In this thesis we introduce our approach to filesystem access control that empowers users to make real-time decisions about which processes or applications should have access to specific filesystem objects. By integrating an interactive decision-making layer into the filesystem, this solution aims to bridge the gap between the security benefits of MAC mechanisms and the simplicity required for widespread adoption. The proposed system delegates access control decisions to the user, enabling them to grant or deny access to individual processes or applications on a per-object basis. This approach not only enhances security but also maintains the flexibility and usability that are critical for user-oriented systems.
 
-The rest of this thesis is organised as follows: \Cref{access} and \cref{current} 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.
+The rest of this thesis is organised as follows: \Cref{access} and \cref{current} provide a review of existing access control mechanisms and their limitations. \Cref{icfs} outlines the design objectives, and the interactive component of the proposed filesystem layer. \Cref{impl} describes the implementation process, including the tools and techniques used to develop the system. Finally, in \cref{eval} we present experimental results, evaluate the performance, security benefits and limitations of the proposed solution, and discuss the potential for further development.

motivation.tex

@@ -5,7 +5,7 @@
 
 \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.
+Many Linux OS ship with additional Mandatory Access Control (MAC) mechanisms (e.g.\ AppArmor, SELinux) that allow to restrict the usage of filesystem objects by specific programs.
 
 Unfortunately, these mechanisms require a considerable amount of knowledge and effort for the user to manage them, which makes them infeasible for most single-user environments.
 
@@ -14,9 +14,9 @@ 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.
+In Lovyagin et. al. 2020 \cite{FGACFS} authors propose and implement a so called FGACFS filesystem that extends traditional UNIX access control policies with far more sophisticated and granular system. This also includes the ability to restrict access on per-program basis. However, due to the sheer variety of options and configurable parameters, this approach still falls short when it comes to ease of use and user-friendliness.
 
-Additionally, 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.
+Additionally, FGACFS and MAC mechanisms described above share a significant drawback: they necessitate user intervention to secure files, even when those files are never accessed. For instance, if access to a filesystem object is denied (allowed) for all programs by default and only allowed (denied) for specific ones, granting (revoking) access for new programs requires users to modify access permissions proactively.
 
 While some solutions offer automatic inheritance or assignment of rules and access control policies, they still need extensive manual configuration. Even if inheriting all access permissions from a default value were practical, installing new programs would always necessitate updating rules to adhere to the principle of least privilege.
 
@@ -24,11 +24,11 @@ Another problem of these solutions, is that their policies are granted forever a
 
 \section{Containerisation}
 
-Another solution to consider, is using containerised software distribution, like Flatpak \cite{FLATPAK}, Snapcraft \cite{SNAP} or AppImage \cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but -- most importantly -- file system objects. 
+Another solution to consider, is using containerised software distribution, like Flatpak \cite{FLATPAK}, Snapcraft \cite{SNAP} or AppImage \cite{APPIMAGE}. Those types of package distribution systems either use Linux feature called \emph{namespaces} or leverage MAC mechanisms to isolate software from the rest of the system. Aside from solving common dependency management problems, this approach also allows some capabilities of the distributed software to be restricted, like access to camera, hardware devices, but -- most importantly -- filesystem objects. 
 
 However, because the developer of the distributed software is responsible for defining the permissions that his own program needs, it often leads to programs having excessive privileges after installation\footnote{It is important to mention, that although this flaw remains unmitigated, the analysis made by Dunlap et al. 2022 \cite{DunlapMAC} shows that most package maintainers actively attempt to define least-privilege application policies.} without any notification of the user.
 
-Additionally, it is a responsibility of the software developer to choose the distribution method, and despite containerised software getting more and more popular, there are still plenty of programs that can only be installed using traditional methods, that do not offer any mechanisms for restricting file system access. 
+Additionally, it is a responsibility of the software developer to choose the distribution method, and despite containerised software getting more and more popular, there are still plenty of programs that can only be installed using traditional methods, that do not offer any mechanisms for restricting filesystem access. 
 
 Furthermore, some software is impractical to sandbox. For example, because of the Flatpak's design, CLI software has to be run with \verb|flatpak run| command and has to use often long and hard-to-remember package names, which may appear rather cumbersome for most users.
 
@@ -57,7 +57,7 @@ Unfortunately, Android access control system is specific to Android. Also, it in
 
 \section{Ranacco}
 
-Finally, in McIntosh et al. 2021 \cite{MCINTOSH} authors propose and implement software called \emph{Ranacco}, which attempts to analyse various system environmental factors (e.g. latest mouse and keyboard activity) and 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.
+Finally, in McIntosh et al. 2021 \cite{MCINTOSH} authors propose and implement software called \emph{Ranacco}, which attempts to analyse various system environmental factors (e.g. latest mouse and keyboard activity) and filesystem operations to detect potentially malicious actions made by processes, in which case it delegates access control decision to the user. This approach avoids the shortcomings of other possible solutions, while remaining easy-to-use. Although this system is more advanced than the one we propose in this thesis, not only is it exclusive to Windows, but it also remains unavailable for the general public.
 
 \section{Requirements for the Solution}
 
@@ -67,7 +67,7 @@ The key issues with existent solutions, that our the system proposed in this the
 \begin{itemize}
 	\item Not all solutions assume processes to be malicious until proven (confirmed by the user to be) safe. Quite often access control permissions are either predefined, inferred or assumed.
 	
-	\item Some solutions can only enforce access policies on software that is distributed in a special way. This leaves the file system just as unprotected against all other software.
+	\item Some solutions can only enforce access policies on software that is distributed in a special way. This leaves the filesystem just as unprotected against all other software.
 	
 	\item Most solutions require passive action from the user besides initial installation (e.g. you have to reconfigure policies all the time). This adds further inconvenience to using such systems.