:D

A lot of stuff happened here. I subdivided the text even more, added the
todonotes package.

accesscontrol.tex

@@ -0,0 +1,35 @@
+\chapter{Filesystem access control on Linux}
+
+\section{Traditional UNIX Filesystem Access Control Policies}
+
+By default, UNIX-like operating systems only provide simplistic Discretionary Access Control (DAC) policies whose objects are files, and subjects are users.
+
+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), that identifies the user that initiated it. 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.
+	\item Otherwise if the process belongs to the group of the file, then the group's access mode is used.
+	\item If neither condition holds, others' access modes are applied.
+	
+\end{itemize}
+
+The access mode is stored in the file's inode, and is set by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
+
+Later, a feature called Access Control Lists (ACL) was introduced to many UNIX-like operating systems and eventually included in the POSIX standard. ACLs provide the ability to control file permissions of specific users, rather than just owner, group and others. Similar to the classic UNIX access control policies, only processes running with the user ID that matches the owner user ID of a file can change its ACLs.
+
+
+\section{The Inherent Flaw}
+
+Although this kind of access control solutions has been proven to be helpful in multi-user environments, it is obviously insufficient to protect against an attack performed by a process initiated by the same user. 
+
+The fundamental weakness of the traditional UNIX DAC model, and even its extension with ACLs, lies in its reliance on user identity as the primary access control decision point. While effective at separating access between different users, it provides little to no protection within a user’s own account. This deficiency is particularly problematic in modern computing environments where a user’s processes are increasingly complex and often involve downloaded or third-party code.
+
+This vulnerability stems from the “all or nothing” nature of user ownership. A process running with user’s EUID inherits all of user’s privileges, treating all files they own as equally accessible. There’s no way to restrict a specific process, even one initiated by the user themselves, from accessing certain files or performing certain operations. 
+
+These limitations highlight the need for more sophisticated access control mechanisms that go beyond simple user identity and consider the context and trustworthiness of the process attempting to access a resource. Mandatory Access Control (MAC) and sandboxing technologies are emerging solutions aiming to address these shortcomings by introducing finer-grained control over process privileges and resource access. The following sections will explore these alternatives in detail.
+
+\todo[inline, author={\textbf{Draft note}}]{Talk more about the threat model?}
+
+

approach.tex

@@ -2,11 +2,9 @@
 
 In this section we present the solution developed as a part of this thesis, named \emph{Interactively Controlled File System} (or ICFS for short).
 
-\section{Features}
+ICFS is a filesystem layer that gives user direct command over its access control. Instead of relying on static policies or rules, it prompts the user for the access control decision via graphical interface. 
 
-ICFS is a filesystem layer that gives user direct command over its access control. Instead of relying on static policies or rules, it prompts the user for the access control decision via graphical interface. When a process tries to open a file, an overlay is displayed, and three options are given: to deny, temporarily allow, or forever allow access to a file.
-
-It is user-friendly and trivially easy to use. It does not introduce any new terminology or complex access control management strategies. The graphical interface is intuitive and self-explanatory. ICFS is configured on the fly: as programs request access, the user's decisions are recorded and later reused. There is no need for any configuration besides installation and choosing a directory to control. It operates on the level of individual processes and files, ensuring high granularity. 
+ICFS is user-friendly and trivially easy to use. It does not introduce any new terminology or complex access control management strategies. The graphical interface is intuitive and self-explanatory. ICFS is configured on the fly: as programs request access, the user's decisions are recorded and later reused. There is no need for any configuration besides installation and choosing a directory to control. It operates on the level of individual processes and files, ensuring high granularity. 
 
 \iffalse
 
@@ -16,12 +14,26 @@ At the same time, it allows for broader, more general rules, which helps to redu
 
 It is backwards compatible: ICFS overrides the regular system call interface using FUSE framework, which means that any software that wishes to use the files ICFS protects has to respect it's policies. Its interactivity combined with the ability to only grant permissions for the lifetime of a specific process makes proxy attacks very difficult to go unnoticed.
 
-\subsection{Access Control Model}
+\section{Access Control Model}
 
-As promised, the access control model of ICFS is trivially simple. It features processes as it's subjects, and files as objects. Whenever a process attempts to access a filesystem object, a dialogue is displayed with three options:
+As promised, the access control model of ICFS is trivially simple. It features processes as it's subjects, and files as objects. Whenever a process attempts to open, remove or change POSIX permissions of an existing file that is not a directory or a symbolic link, and this process does not already have access to this file, a dialogue is displayed with three options:
 
 \begin{itemize}
-	\item \emph{Allow}, that will allow this process and any other process that is started with the same executable to access the filesystem object.
-	\item \emph{Allow this time}, that will allow the requesting process to access the filesystem object for it's runtime.
-	\item \emph{Deny}, that will deny all access to the filesystem object.
+	\item \emph{Allow}, that will allow this process and any other process that is started with the same executable to access the file.
+	\item \emph{Allow this time}, that will allow the requesting process to access the file.
+	\item \emph{Deny}, that will deny all access to the file.
 \end{itemize}
+
+\missingfigure[figcolor=white]{ICFS access dialogue}
+
+\todo[inline, author={\emph{Draft note}}]{Too much stuff per section? Divide by the issues from previous chapter?} 
+
+Decisions made in the dialogues are recorded and later reused when processes access files again.
+
+On the other hand, if a process attempts to create a file, it is automatically granted permanent access to the file it has created.
+
+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.
+
+The choice to not require access granting for file \emph{creation} is also based in simplicity. If a process can't modify or edit any existing data by creating new files, then there is little use in restricting it.

conclusion.tex

@@ -2,4 +2,6 @@
 \addcontentsline{toc}{chapter}{Conclusion} % rucne pridanie do obsahu
 \markboth{Conclusion}{Conclusion} % vyriesenie hlaviciek
 
+\todo[inline, author={\textbf{Draft note}}]{This chapter is \emph{very} incomplete.} 
+
 In conclusion, the overall value and benefits of the solution is discussed(reiterated \verb|:)|). 

evaluation.tex

@@ -1,5 +1,7 @@
 \chapter{Evaluation}
 
+\todo[inline, author={\textbf{Draft note}}]{This chapter is \emph{very} incomplete, and only contains a rough sketch of how it is supposed to look. This is not the actual thesis-worthy text.} 
+
 In this chapter presents the method of evaluating the solution is presented, and the found qualities of the solution are discussed.
 
 Specifically this includes:

main-en.tex

@@ -8,6 +8,8 @@
 \usepackage[T1]{fontenc}
 %nice code
 \usepackage{minted}
+%todos
+\usepackage[textwidth=20mm]{todonotes}
 
 %zapnutie slovenskeho delenia slov
 %a automatickych nadpisov ako Obsah, Obrázok a pod. v slovencine
@@ -266,9 +268,15 @@ or deny access to a filesystem object by a specific process to the user.
 \mainmatter
 \pagestyle{headings}
 
+% -------------------
+% --- REMOVE BEFORE PUBLISHING
+% -------------------
+% Todo list
+\listoftodos
+
 \input intro.tex
 
-%\input accesscontrol.tex
+\input accesscontrol.tex
 
 \input motivation.tex
 

motivation.tex

@@ -1,37 +1,16 @@
 
 
-\chapter{Motivation}
+\chapter{Current solutions, and why they won't suffice}
 
-\section{Limitations of Traditional UNIX File Access Control Policies}
+\section{MAC mechanisms}
 
-By default, UNIX-like operating systems only provide simplistic Discretionary Access Control (DAC) policies whose objects are files, and subjects are users.
+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.\todo[inline, author={\textbf{Draft note}}]{Explain how exactly can they do that? (It seems irrelevant to the overall topic)} 
 
-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.
+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.
 
-Each process has it's own \textit{Effective User ID} (EUID), that identifies the user that initiated it. 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.
-	\item Otherwise if the process belongs to the group of the file, then the group's access mode is used.
-	\item If neither condition holds, others' access modes are applied.
-	
-\end{itemize}
 
-The access mode is stored in the file's inode, and is set by a process with the file owner's user ID using the \texttt{chmod} system call. The file owner is the user who created the file, and can be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser. The group of a file is set to the group of the file owner when the file is created, and can also be changed using the \texttt{chown} system call by a process with the effective user ID of a superuser.
-
-Later, a feature called Access Control Lists (ACL) was introduced to many UNIX-like operating systems and eventually included in the POSIX standard. ACLs provide the ability to control file permissions of specific users, rather than just owner, group and others. Similar to the classic UNIX access control policies, only processes running with the user ID that matches the owner user ID of a file can change its ACLs.
-
-Although this kind of access control solutions has been proven to be helpful in multi-user environments, it is obviously insufficient to protect against an attack performed by a process initiated by the same user. 
-
-The fundamental weakness of the traditional UNIX DAC model, and even its extension with ACLs, lies in its reliance on user identity as the primary access control decision point. While effective at separating access between different users, it provides little to no protection within a user’s own account. This deficiency is particularly problematic in modern computing environments where a user’s processes are increasingly complex and often involve downloaded or third-party code.
-
-This vulnerability stems from the “all or nothing” nature of user ownership. A process running with user’s EUID inherits all of user’s privileges, treating all files they own as equally accessible. There’s no way to restrict a specific process, even one initiated by the user themselves, from accessing certain files or performing certain operations. 
-
-These limitations highlight the need for more sophisticated access control mechanisms that go beyond simple user identity and consider the context and trustworthiness of the process attempting to access a resource. Mandatory Access Control (MAC) and sandboxing technologies are emerging solutions aiming to address these shortcomings by introducing finer-grained control over process privileges and resource access. The following sections will explore these alternatives in detail.
-
-\section{Current solutions}
-
-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. 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.
+\section{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.
 
@@ -41,6 +20,8 @@ While some solutions offer automatic inheritance or assignment of rules and acce
 
 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.
 
+\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. 
 
 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.
@@ -49,14 +30,20 @@ Additionally, it is a responsibility of the software developer to choose the dis
 
 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}
+
 Another, similar solution can be found in the Android operating system. Here, all apps are sandboxed by default. But Android does way more than Flatpak: it adds an interactive component to the access control.
 
 When an app need permission to access the shared storage (part of the filesystem, common to all applications), an overlay is displayed, prompting the user for their decision on whether to allow or deny access to user's files. Notably, this approach avoids the problem of granting permissions up front, and always informs the user about the permissions that the app wishes to have.
 
+\missingfigure[figcolor=white]{Picture of an Android permissions dialogue.}
+
 Furthermore, starting in Android 11, whenever an app requests a permission related to location, microphone, or camera, the user-facing permissions dialogue contains an option called ''Only this time``. If the user selects this option in the dialogue, the app is granted a temporary one-time permission.\cite{ANDR11PERM}
 
 Unfortunately, Android access control system is specific to Android. Also, it inherits the already mentioned drawbacks of containerisation, and only works through special API, thus requiring the software to be redesigned to work with such an access control system.
 
+\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
 
@@ -64,6 +51,10 @@ Overall, there appears to be little research on systems that actively involve us
 
 \fi
 
+\section{Requirements for the solution}
+
+\todo[inline, author={\textbf{Draft note}}]{Negate the statements? (state what we want, not what we don't want)}
+
 The key issues with existent solutions, that our the system proposed in this thesis will try to address are as follows:
 \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.