96 lines
12 KiB
TeX
96 lines
12 KiB
TeX
|
||
|
||
\chapter{Motivation}
|
||
|
||
\section{Limitations of Traditional UNIX File 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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Another, similar solution can be found in the Android operating system. Here, all apps are sandboxed by default. 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.
|
||
|
||
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 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
|
||
|
||
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.
|
||
|
||
\iffalse
|
||
\item Some solutions run inside of 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.
|
||
|
||
\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
|
||
|
||
|