101 lines
9.6 KiB
TeX
101 lines
9.6 KiB
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.\todo[inline, author={\textbf{Draft note}}]{Explain how exactly can they do that? (It seems irrelevant to the overall topic)}
|
|
|
|
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.
|
|
|
|
Additionally, all the above solutions 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 \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.
|
|
|
|
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.
|
|
\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}
|
|
|
|
%\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}
|
|
|
|
\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
|
|
|
|
|