:)

approach.tex

@@ -64,6 +64,8 @@ The dialogue contains three functional elements:
 
 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.
 
+To resolve situations, where user sets conflicting permissions with different scopes, only the more specific permission's effect is applied. For example, if user first allows a process to access \verb|~/Documents/book.pdf|, but later also denies access to \verb|~/Documents/|, then the process is allowed to access \verb|~/Documents/book.pdf|, but no other files in \verb|~/Documents/|. 
+
 This model addresses five key limitations of traditional systems:
 
 \begin{itemize}
@@ -94,22 +96,4 @@ While this approach increases the potential for malicious processes to disrupt o
 
 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}.
-
-
-\iffalse
-
-However, if the above rules were followed literally, the ICFS would be \emph{very} tiring to use. To illustrate this, let's consider the following example: the user has a \TeX document in the \verb|/home/user/Documents/main.tex| file. Now they want to edit the file using their text editor of choice, \verb|vim|. At the first glance, it might seem like the user would be accessing just one file, but the reality is that they are actually accessing four files: three directories and one file. If the above rules were followed literally, \verb|vim| would require permission to each file in the path\footnote{Assuming ICFS is mounted at root. This is not recommended, even if possible.} to actually read data from a single file.
-
-Situations like this are the reason ICFS does not require permission for the process to access directories. The only thing that a malicious process can gain from this relaxation of the original restrictions is the ability to see the directory structure, which is unlikely to contain any kind of sensitive data.
-
-Now, let's slightly change our example. Now, let \verb|/home/user/Documents/main.tex| be a symbolic link to the \verb|/home/user/Documents/real_main.tex| file. From standpoint of the user it might seem like they are accessing just one file.
-
-
-
-We chose this model because of its simplicity. Having more options in the dialogue induced heavy choice fatigue of the user, since programs typically open a lot of files throughout their runtime. Even simple text editors open lock and backup files besides the target file. Programs like TeXstudio or programming IDEs open dozens of files simultaneously, since they need all kinds of temporary and configuration files.
-
-We chose to give processes unlimited access to directories and symbolic links because they do not contain any data on their own. Having to grant access to every folder on the path to the file is simply too tedious for anyone.
-
-\fi
-
+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}.

conclusion.tex

@@ -2,4 +2,12 @@
 \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.
 
+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.
+
+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.
+
+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.
+
+In conclusion, ICFS represents a significant step toward simplifying advanced access control mechanisms by aligning security enforcement with user intuition. While its current iteration exposes inherent challenges in balancing dynamic policy enforcement with system complexity, the framework provides a foundational model for future innovations in user-driven cybersecurity solutions. By addressing the outlined limitations, subsequent development could further bridge the divide between academic security paradigms and practical, user-friendly implementation.

motivation.tex

@@ -57,11 +57,6 @@ 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.
-\iffalse
-
-Overall, there appears to be little research on systems that actively involve users in access control decision-making. Most of the literature on alternative access control systems either focuses on passive policy regulation intended for large multi-user systems, which has the same drawbacks as the already mentioned default Linux access control systems, or on systematic analysis of access control vulnerabilities (Parkinson et al.) \cite{BIGSURSTAT}. 
-
-\fi
 
 \section{Requirements for the solution}
 
@@ -80,21 +75,4 @@ The key issues with existent solutions, that our the system proposed in this the
 	\item Majority of solutions focus on preventing unwanted access by other users, which makes it unsuitable for single-user environments.
 	
 	\item Solutions are either overly complex and not user-friendly, or too simplistic to provide adequate granularity of permissions. This either leads to slower adoption of such systems, or makes them insufficient at protecting user data.
-\end{itemize}
-
-\iffalse
-
-The key differences of the software proposed in this article to those already mentioned and researched (to the best of our knowledge) are as follows:
-\begin{itemize}
-	\item Unlike other approaches, proposed software assumes all processes to be malicious until proven (confirmed by the user to be) safe. All of the access control permissions are granted as-needed, not predefined, inferred or assumed.
-	\item Proposed software provides potentially high (e.g. can be granted on per-object basis), and flexible granularity of permissions.
-	\item Proposed software is intuitive and simple-to-use. It's usage does not require prior knowledge of advanced access control policies.
-	\item Proposed software runs entirely in user space. This reduces possibilities for system-breaking bugs, and make installation trivially simple.
-	\item Proposed software does not require programs to use any special API or be packaged in any special way. All programs will have to respect policies enforced by our software.
-	\item Proposed software does not require any passive action from the user besides initial installation (e.g. you don't have to reconfigure policies all the time).
-	\item Proposed software grants permissions temporarily, which reduces attack surface compared to other methods.
-\end{itemize}
-
-\fi
-
-
+\end{itemize}