:D

accesscontrol.tex

@@ -21,7 +21,7 @@ The access mode is stored in the file's inode, and is set by a process with the
 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}
+\section{The Inherent Flaw of User-Centric Access Control}
 
 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. 
 

approach.tex

@@ -12,7 +12,6 @@ Key Features:
 	\item Dynamic Policy Enforcement: Permissions are established on-demand and stored for future reference, minimizing repetitive prompts.
 	\item Granular Control: Policies apply at the process-file level, with options to generalize rules for broader categories, reducing user fatigue.
 	\item Backward Compatibility: Implemented via the FUSE framework, ICFS intercepts system calls without altering existing software workflows. 
-	\item Time-bound permissions ??
 \end{itemize}
 
 \section{Usage}
@@ -37,8 +36,6 @@ ICFS adopts a straightforward access control model:
 
 When a process requests access (e.g., open, modify, delete) to a file without pre-existing permissions, ICFS generates an access dialogue (see Figure \ref{fig:dialogue}).
 
-%\missingfigure[figwidth=9cm ,figcolor=white]{ICFS access dialogue}
-
 \begin{figure}[H]
 	\centering
 	\includegraphics[width=0.6\linewidth]{./images/icfs-dialogue-window.png}
@@ -55,8 +52,8 @@ The dialogue contains three functional elements:
 		\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 labeled "Permanent" allows the user to persist the access decision beyond the current process.
-	If checked , the permission rule (allow/deny) is stored in a local configuration database. The rule then applies to all future access attempts by processes with an executable filename matching the requesting process.
-	If unchecked , the decision applies only to the requesting process. That is, the process can actually access the file multiple times with this permission.
+	If checked , the permission rule (allow/deny) is stored in a local configuration database. The rule then applies to all future access attempts by processes (and any of their child processes) with an executable filename matching the requesting process.
+	If unchecked , the decision applies only to the requesting process and it's child processes. That is, the process can actually access the file multiple times with this permission.
 	Permissions granted with this box toggled on (off) will from now on be referred to as ''permanent`` (''temporary``).
 	\item File Path Substitution Field: A text input field pre-filled with the absolute path of the requested file. Users may edit this field to modify scope of the permission (e.g., granting access to all files in the parent directory instead of a single file).
 \end{itemize}
@@ -91,6 +88,11 @@ Second, processes are permitted to create files without restriction. This decisi
 
 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:limit} of \autoref{eval}.
 
+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:limit} of \autoref{eval}.
+
+
 \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.

implementation.tex

@@ -8,7 +8,7 @@ This chapter outlines the software design and architecture of ICFS, detailing ho
 
 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.
 
-ICFS implements this API in C using the libfuse3 library. 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 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 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.
 
@@ -18,6 +18,8 @@ To enforce access restrictions, ICFS mounts directly over the target directory,
 
 To enforce an access control policy over time, filesystem needs to store user decisions in an appropriate data structure. As described in \autoref{icfs:model}, ICFS can give out two types of permissions: temporary and permanent. To accommodate this access control model, ICFS implements two data structures: a temporary permissions table, and a permanent permissions table, which we describe in detail in \autoref{impl:temp} and \autoref{impl:perm} respectively.
 
+To pass permissions to child processes, both tables use procfs. When a permission check for the requesting process yields no results, recursive checks are performed on parent processes by traversing the process tree.
+
 \subsection{Temporary permissions}
 \label{impl:temp}
 
@@ -34,8 +36,19 @@ At first, it might seem that factoring in start time is excessive. However, only
 
 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, that is 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.
+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).
+
+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. We discuss its effect on performance in the \autoref{eval}.
 
 \subsection{Permanent permissions}
 \label{impl:perm}
 
+Since permanent permissions are granted to all processes' with the same executable, only it's filename is needed for identification. Since the permissions have to persist after filesystem restart, the table needs to be stored on the disk. Hence, we chose SQLite \cite{SQLITE} as the backend for the permanent permissions table. It is well-tested and lightweight, making it an ideal choice for a program like ICFS.
+
+Due to specifics of relational databases, the permissions are stored as a relation  \allowbreak$(executable, filename, type)$, where $executable$ is the filename of the executable, $filename$ is a filename of the file that the permission targets and $type$ is a boolean value indicating whether the permission allows or prohibits access to the target file.
+
+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}.

intro.tex

@@ -3,20 +3,6 @@
 \addcontentsline{toc}{chapter}{Introduction}
 \markboth{Introduction}{Introduction}
 
-\iffalse
-
-The introduction contains:
-
-\begin{itemize}
-	\item the state of things
-	\item The problem
-	\item Existing solutions and why they don't work
-	\item our approach
-	\item the layout of the thesis
-\end{itemize}
-
-\fi
-
 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.

literatura.bib

@@ -109,4 +109,25 @@
 	author = {Jackson L. Allan},
 	year = {2025},
 	url = {https://github.com/JacksonAllan/CC}
+}
+
+@online{SOPROCNOTIF,
+	title = {c++ - How to get notified when a process ends under linux? - Stack Overflow},
+	year = {2016},
+	url = {https://stackoverflow.com/questions/34800568/how-to-get-notified-when-a-process-ends-under-linux}
+}
+
+@online{SQLITE, 
+	title={{SQLite}},
+	url={https://www.sqlite.org/index.html},
+	version={3.47.2},
+	year={2024},
+	author={Hipp, Richard D}
+}
+
+@online{LIBFUSE,
+	title={{libfuse}},
+	url={https://github.com/libfuse/libfuse},
+	version={3.17.2},
+	year={2025},
 }

motivation.tex

@@ -74,10 +74,6 @@ The key issues with existent solutions, that our the system proposed in this the
 	\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 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.
-
-\iffalse
-	\item Some solutions run inside the kernel. This makes bugs particularly dangerous, and complicates the installation process.
-\fi
 	
 	\item Most solutions grant permissions forever, which significantly increases attack surface. Specifically, this opens up possibilities for attacks by proxy.