ICFS-thesis/motivation.tex

\chapter{Current Solutions, and Why They Won't Suffice}
\label{current}

\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.

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}
\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, 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 \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. 

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.

\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.

\begin{figure}[H]
	\centering
	\begin{subfigure}[b]{0.4\linewidth}
		\includegraphics[width=\linewidth]{./images/permission-dialogue-organic-maps.jpg}
		\caption{}
	\end{subfigure}
	\begin{subfigure}[b]{0.5\linewidth}
		\includegraphics[width=\linewidth]{./images/permission-dialogue-smart-scan.jpg}
		\caption{}
	\end{subfigure}
	\caption{Permissions dialogues in Android 14: The location access permission dialogue (a) shows three options: ``While using the app'', ``Only this time'' and ``Don't allow''. The media access permission dialogue also has three, but different options: ``Allow limited access'', ``Allow all'' and ``Don't allow''}
\end{figure}

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.

\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.
	
	\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.
	
	\item Most solutions grant permissions forever, which significantly increases attack surface. Specifically, this opens up possibilities for attacks by proxy.
	
	\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}