37 lines
3.8 KiB
TeX
37 lines
3.8 KiB
TeX
\chapter{Filesystem access control on Linux}
|
||
\label{access}
|
||
|
||
\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), the user that the process is running on behalf of. 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 can be changed 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 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.
|
||
|
||
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 chapter will explore these alternatives in detail.
|
||
|
||
\todo[inline, author={\textbf{Draft note}}]{Talk more about the threat model?}
|
||
|
||
|