:)

accesscontrol.tex

@@ -25,12 +25,11 @@ Later, a feature called Access Control Lists (ACL) was introduced to many UNIX-l
 
 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.
+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. 
+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?}
 
 

approach.tex

@@ -16,11 +16,15 @@ Key Features:
 
 \section{Usage}
 
-To deploy ICFS, the user selects a target directory and executes:
+To deploy ICFS, the user selects a target directory and executes the command as shown in \autoref{icfs:usage:cmd}
 
+\begin{figure}[!ht]
 \begin{minted}{bash}
-	icfs path/to/directory
+icfs <FUSE arguments> [mounpoint] [permission database] <ICFS arguments>
 \end{minted}
+\caption{Command that mounts ICFS over the folder denoted as [mounpoint], while using the permanent permission database stored in the file denoted as [permission database]. <ICFS arguments> and <FUSE arguments> denote ICFS arguments and libfuse arguments respectively.}
+\label{icfs:usage:cmd}
+\end{figure}
 
 This mounts ICFS over the specified directory, enforcing access control for all subsequent interactions. While the name includes "File System," ICFS operates as a filesystem layer , intermediating between the physical filesystem (e.g., ext4) and user processes. It preserves the appearance of the original filesystem while enforcing its own access logic (implementation details in \autoref{impl:fuse}).
 
@@ -51,14 +55,14 @@ The dialogue contains three functional elements:
 		\item Yes Button : Grants temporary access to the requested file to the requesting process only. If the user selects this option, the process is allowed to proceed with the requested access (e.g., read, write).
 		\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.
+	\item Permanent Permission Checkbox: A toggle labelled "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 (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}
 
-Behaviour changes slightly, if the operation is performed on a directory or a symbolic link: If the file is a directory, only changing the access mode and removal require permission from the user. With symbolic links, following is always permitted. If a process attempts to create a file, it is automatically granted permanent access to the file it has created.
+Behaviour changes slightly, if the operation is performed on a directory or a symbolic link: If the file is a directory, only changing the access mode and removal require permission from the user. With symbolic links, following is always permitted. If a process attempts to create a file, it is automatically granted temporary access to the file it has created.
 
 This model addresses five key limitations of traditional systems:
 
@@ -72,7 +76,7 @@ The remaining two criteria are analysed in the next section.
 
 \section{Least Privilege vs. Usability}
 
-Balancing the principle of least privilege with usability posed the greatest design challenge. Strict enforcement—prompting for every access attempt—would minimize risk but overwhelm users.
+Balancing the principle of least privilege with usability posed the greatest design challenge. Strict enforcement -- prompting for every access attempt -- would minimize risk but overwhelm users.
 
 To reduce friction, ICFS needs to keep the number of dialogues to minimum. This necessitates avoiding prompts for actions likely to be safe. However, we still aim to avoid granting excessive privileges by default.
 
@@ -86,11 +90,11 @@ Firstly, Unlike POSIX, ICFS does not restrict directory visibility. While this e
 
 Second, processes are permitted to create files without restriction. This decision is based on the observation that many programs create auxiliary and temporary files. For instance, the pdfLaTeX compiler creates 21 files in the source directory for this thesis, only 10 of which are human-editable; the remaining files are intermediary output of the compiler. Requiring the user to grant permissions for all these files would more than double the decision-making burden.
 
-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}.
+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:sec}.
 
 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}.
+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:sec}.
 
 
 \iffalse

conclusion.tex

@@ -2,6 +2,4 @@
 \addcontentsline{toc}{chapter}{Conclusion} % rucne pridanie do obsahu
 \markboth{Conclusion}{Conclusion} % vyriesenie hlaviciek
 
-\todo[inline, author={\textbf{Draft note}}]{This chapter is \emph{very} incomplete.} 
 
-In conclusion, the overall value and benefits of the solution is discussed(reiterated \verb|:)|). 

evaluation.tex

@@ -1,47 +1,36 @@
-\chapter{Evaluation}
+\chapter{Results}
 \label{eval}
 
-We tried to asses the quality of ICFS by the following metrics:
+We tried to assess the quality of ICFS by the following metrics:
 
 \begin{itemize}
 	\item Security : Does ICFS effectively mitigate unauthorized access by untrusted processes?
 	\item Usability : Does the interactive model reduce configuration burden while maintaining user control?
 	\item Performance : What is the overhead introduced by ICFS compared to native filesystem operations?
-	\item Compatibility : How well does ICFS integrate with existing workflows and software (e.g., CLI tools, legacy applications)?
 \end{itemize}
 
 \section{Test environment}
 
-Performance and usability evaluations were conducted on an HP Pavilion Laptop 15-cc563st equipped with an Intel® Core™ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND M.2 SATA SSD (250GB), and 12 GB of DDR4 RAM. The system ran Fedora Linux 42 (Workstation Edition) with kernel version 6.14.5-300.fc42.x86\_64 and GNOME 48 under the Wayland session. For additional compatibility testing, a KVM virtual machine hosted on the same hardware emulated a Debian GNU/Linux 12 (bookworm) environment with kernel 6.1.0-27-amd64, GNOME 43.9, and the X11 windowing system. The virtual machine had 2 CPU cores and 2 GB of RAM.
+Performance and usability evaluations were conducted on an HP Pavilion Laptop 15-cc563st equipped with an Intel® Core™ i7-7500U processor, a Western Digital WDS250G2B0B WD Blue 3D NAND M.2 SATA SSD (250GB), and 12 GB of DDR4 RAM. The system ran Fedora Linux 42 (Workstation Edition) with kernel version 6.14.5-300.fc42.x86\_64 and GNOME 48 under the Wayland session, and a btrfs-formatted disk. For additional compatibility testing, a KVM virtual machine hosted on the same hardware emulated a Debian GNU/Linux 12 (bookworm) environment with kernel 6.1.0-27-amd64, ext4 filesystem, GNOME 43.9, and the X11 windowing system. The virtual machine had 2 CPU cores and 2 GB of RAM.
 
-To simulate real-world usage, ICFS was mounted to a directory pre-populated with files, and interactions were tested across six widely used applications:
+To simulate real-world usage, ICFS was mounted to a directory pre-populated with files, and interactions were tested across eight widely used applications:
 
 \begin{itemize}
 	\item {\TeX}studio.
 	\item Programming IDE/text editor (Neovim).
+	\item Markdown editor (Apostrophe).
 	\item A web browser (Mozilla Firefox).
 	\item File manager (GNOME Files, also known as Nautilus).
 	\item File synchronisation software (Syncthing).
 	\item Standard command line core utilities (e.g. \verb|ls|, \verb|cd|, \verb|grep|, ...).
 \end{itemize}
 
-These tools were selected for their prevalence and diverse filesystem interaction patterns. Except for Syncthing and Firefox (distributed via Flatpak containers), all applications were installed as native packages. 
-
-\iffalse
-
-For performance testing, special scripts were written, that test the speed of `open` operations. We did not test other operations, since 
-
-\fi
-
-\todo[inline, caption={Complete Evaluation}, author={\textbf{Draft note}}]{The rest of this chapter is \emph{very} incomplete, and only contains a brief and informal talk about the issues I am facing right now. This is not the actual thesis-worthy text. All issues discussed were relevant as of 13.05.2025} 
-
-\section{Security}
-
-\todo[inline, author={\textbf{Draft note}}]{What to even say here?}
+These tools were selected for their prevalence and diverse filesystem interaction patterns. Except for Syncthing, Apostrophe (distributed via Flatpak containers) and Firefox (Flatpak and native versions), all applications were installed as native packages. 
 
 \section{Usability}
 
-Testing revealed that most applications interacted smoothly with ICFS. TeXstudio and Neovim required a single permission prompt when opening existing projects, with no further interruptions for new file creation.
+Testing revealed that most applications interacted smoothly with ICFS. Command line utilities, Syncthing, Apostrophe, TeXstudio and Neovim required a single permission prompt when opening existing files, with no further interruptions for new file creation. Furthermore, they have only maintained access to files they actually needed to function.
+
 
 GNOME Files (Nautilus) exhibited unexpected behaviour. While functional without access permissions, its thumbnail generation process triggered repeated prompts. The file manager employs an external utility, gdk-pixbuf-thumbnailer, to create previews of files such as images. 
 
@@ -53,7 +42,7 @@ GNOME Files (Nautilus) exhibited unexpected behaviour. While functional without
 
 Each preview required individual authorisation because the thumbnailer operates per-file, invalidating temporary folder permissions after each new image access. A pragmatic solution involves granting permanent access to the thumbnailer for specific directories -- a trade-off between convenience and security.
 
-Firefox interactions were limited to file downloads and uploads, which utilise system-level file selection dialogs managed by the system file manager.
+Firefox interactions were limited to file downloads and uploads, which utilise system-level file selection dialogues provided by \verb|xdg-desktop-portal| service, and managed by the system file manager.
 
 \begin{figure}[H]
 	\centering
@@ -61,15 +50,47 @@ Firefox interactions were limited to file downloads and uploads, which utilise s
 	\caption{File selection dialogue in Firefox.}
 \end{figure}
 
-Hence, it inherited all issues Nautilus had. However, denying Nautilus permissions did not disrupt the download process itself, and ensured users could selectively authorise only the target save location -- a critical safeguard for internet-facing applications.
+Hence, it inherited all the usability issues Nautilus had. This dependency also introduced security implications discussed in the following section.\footnote{Only the Flatpak version of Firefox was affected.}
 
-Containerisation significantly impacted Syncthing ’s usability. Flatpak-packaged applications often modify filesystem paths visible within their sandbox. In Syncthing’s case, the executable’s relocated path invalidated \verb|/proc/pid/exe| -- a symbolic link in Linux’s procfs filesystem that typically points to a process’s binary. ICFS relies on this link to verify process identities for persistent permissions.
+Impact on shell script usability was significant. Since each shell command spawns a new process, users must grant permissions for every command individually.\footnote{Permanent permissions for core shell utilities are discouraged, as they expose the filesystem to unrestricted access via these tools.} A partial mitigation involved redirection operators (\verb|>|, \verb|>>|), which force the shell interpreter to handle file operations, allowing child processes to inherit permissions. However, this approach breaks compatibility with existing scripts. This limitation was anticipated, and potential solutions are discussed in \autoref{eval:future}.
+
+\section{Security}
+\label{eval:sec}
+
+While ICFS represents a significant improvement over traditional access control systems in single-user environments, its design contains notable limitations.
+
+ICFS theoretically allows users to control every filesystem access operation, but the system's security depends heavily on the user's ability to interpret and respond to access requests. Despite efforts to make the interface accessible, the system generates prompts that may confuse average users. For example, access attempts by Apostrophe were displayed as actions by \verb|/usr/bin/python3.12|. This occurs because Apostrophe is written in Python, an interpreted language: all Python programs execute under the Python interpreter, causing dialogues to display the interpreter path rather than the application name. This limitation stems from ICFS's permission system, which tracks processes at the executable level. Users must understand this behavior to avoid inadvertently granting interpreters permanent access to files, which would expose them to all scripts executed by the interpreter.
+
+Another challenge arises with Flatpak-packaged applications, which often obscure filesystem paths within their sandboxes. For instance, Syncthing's relocated executable path invalidated \verb|/proc/pid/exe|, the mechanism ICFS uses to resolve process identities via the \verb|readlink| system call. Current implementations rely on unvalidated paths returned by \verb|readlink|, leaving the system vulnerable to attacks where malicious processes mask their identity by manipulating sandboxed paths.
+
+A larger, unresolved issue involves the \verb|xdg-desktop-portal| daemon. To unify file-chooser interfaces across desktop environments, this background service handles file opening operations on behalf of requesting processes via D-Bus\footnote{D-Bus is an inter-process communication method on Linux.}. The open file descriptors are then passed to the requesting processes, allowing it to use the file normally. While simplifying file management, the daemon prevents ICFS from identifying the original requesting process, thereby undermining granular access control.
+
+A critical unresolved issue involves the \verb|xdg-desktop-portal| daemon, which centralises file-chooser interfaces across desktop environments. By handling file operations on behalf of requesting processes via D-Bus,\footnote{D-Bus is an inter-process communication mechanism in Linux.} the daemon obscures the original process, undermining ICFS's granular access control.
+
+Consequently, files created through \verb|xdg-desktop-portal| become accessible to any process using the daemon. To address this, the \verb|--no-perm-on-create| flag disables permission grants during file creation. However, \verb|xdg-desktop-portal| retains user-controlled file selection via graphical interfaces, ensuring safety\footnote{That is, safety equivalent to ICFS, since both of them depend on the inaccessibility of GUI interaction by foreign processes.} in this context. This highlights a broader concern: similar behaviours in other daemons may exist, even if undetected in our analysis.
+
+\subsection{Safety of graphical interfaces}
+
+While ICFS's access control system deters unprepared attackers, programmatic GUI interaction by an informed attacker poses a valid attack vector. ICFS relies on the assumption that GUI interactions are inaccessible to unprivileged processes; otherwise, an attacker could programmatically grant themselves permissions.
+
+On X11 systems, tools like xdotool \cite{XDOTOOL} enable unprivileged processes to simulate keystrokes and interact with windows, as verified in our Debian testing environment. In contrast, Wayland's security model restricts such interactions: xdotool and its Wayland equivalent, ydotool \cite{YDOTOOL}, cannot interfere with windows without explicit user permission via GNOME's graphical dialogues or superuser configuration.
+
+Theoretical risks remain via AT-SPI accessibility protocols, which could potentially interact with access dialogues. As a preventive measure, ICFS disables all accessibility features in access dialogues. However, this issue was not fully investigated within the scope of this thesis. Further research is needed to identify and address other potential attack vectors through desktop environment interfaces.
 
 \section{Performance}
 
-Performance of ICFS is terrible. \sout{Unfortunately, I was unable to make perf work with it for some reason, so I don't really know what is slowing operations down. So those are my speculations for what \emph{may} be the bottleneck. A lot of it is caused by it's design. For example, ICFS needs to look through procfs to get process creation time, and there is no way of going around this it seems.}
+Performance testing revealed a substantial impact on filesystem operations. A bash script opening large volumes of files in parallel ran in 0.714s on bare btrfs, 16.189s with temporary ICFS permissions, and 33.409s with permanent permissions. While ICFS's access control layer likely affects other operations, these were not tested as they fall outside its scope.
 
-I managed to get the \verb|perf| to work: it showed that almost all time was consumed by libfuse, not my program. My code used something like 0.0001\% of runtime on a pretty heavy test. I am not quite sure what to do, since libfuse is already optimised to smithereens. I guess I will just write how it is and not touch the performance ever again.
+Despite these synthetic benchmarks, real-world usability remained unaffected. Applications with intensive filesystem usage, such as Syncthing, experienced no critical slowdowns.
+
+\section{Future work}
+\label{eval:future}
+
+Current version of ICFS lacks a way to edit permissions once they were granted. A solution would be to develop a simple tool that would communicate with ICFS daemon through a UNIX domain socket owned by a special user, and be able to open and edit the permanent permissions database via sqlite3 library.
+
+A critical area for future refinement lies in addressing vulnerabilities stemming from programmatic interactions with graphical interfaces. ICFS currently assumes that GUI interactions remain inaccessible to unprivileged processes, yet this premise is challenged by tools like xdotool (on X11 systems), which can simulate keystrokes and manipulate windows without user consent. While Wayland's stricter isolation policies mitigate this risk -- requiring explicit user approval via GNOME dialogues or superuser privileges for tools like ydotool -- other exploits might be available to attackers, that were left unexplored in this thesis.
+
+Security limitations demand deeper integration with sandboxing frameworks. The current reliance on resolving process identities via /proc/pid/exe proves insufficient in containerized environments, where executable paths are virtualized. The reliance of ICFS on process-level identity introduces challenges when interacting with containerised applications, which obscure the original requesting process. Future work could explore deeper integration with such services to propagate context-aware permissions. For example, ICFS might integrate with Flatpak permission system to coordinate access control, possibly even set Flatpak sandbox permissions via graphical access dialogues (which Flatpak currently lacks).
+
+The current design's requirement for per-process permission grants creates friction for shell scripting, where new processes are frequently spawned. A potential solution involves implementing a session-based model, allowing the user to grant permissions to all processes with matching session ID (which typically corresponds to a single shell instance or script). This approach would preserve security while maintaining compatibility with existing scripts.
 
-\section{Limitations}
-\label{eval:limit}

implementation.tex

@@ -12,7 +12,7 @@ ICFS implements this API in C using the libfuse3 library \cite{LIBFUSE}. It init
 
 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.
 
-To enforce access restrictions, ICFS mounts directly over the target directory, intercepting all access requests directed to it. As part of Linux’s Virtual Filesystem (VFS) architecture, processes interacting with the protected directory are routed through ICFS. However, ICFS retains direct access to the underlying files by opening the directory with the \verb|O_PATH| flag before mount. Subsequent operations are executed using "at"-suffixed system calls like \verb|openat()|, performed directly at the file descriptor level\cite{MANOPEN}, which bypasses ICFS's own layer.
+To enforce access restrictions, ICFS mounts directly over the target directory, intercepting all access requests directed to it. As part of Linux's Virtual Filesystem (VFS) architecture, processes interacting with the protected directory are routed through ICFS. However, ICFS retains direct access to the underlying files by opening the directory with the \verb|O_PATH| flag before mount. Subsequent operations are executed using "at"-suffixed system calls like \verb|openat()|, performed directly at the file descriptor level\cite{MANOPEN}, which bypasses ICFS's own layer.
 
 \section{Permission tables}
 
@@ -40,7 +40,7 @@ In our implementation, entries are organised in a hash map, with PIDs as keys. T
 
 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}.
+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.
 
 \subsection{Permanent permissions}
 \label{impl:perm}
@@ -51,4 +51,4 @@ Due to specifics of relational databases, the permissions are stored as a relati
 
 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}.
+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:future}.

literatura.bib

@@ -130,4 +130,31 @@
 	url={https://github.com/libfuse/libfuse},
 	version={3.17.2},
 	year={2025},
+}
+
+@online{XDOTOOL,
+	title={{jordansissel/xdotool: fake keyboard/mouse input, window management, and more}},
+	url={https://github.com/jordansissel/xdotool},
+	version={3.20211022.1},
+	year={2021},
+}
+
+@online{YDOTOOL,
+	title={{ReimuNotMoe/ydotool: Generic command-line automation tool (no X!)}},
+	url={https://github.com/ReimuNotMoe/ydotool},
+	version={1.0.4},
+	year={2021},
+}
+
+@software{tange_2024_14550073,
+	author       = {Tange, Ole},
+	title        = {GNU Parallel 20241222 ('Bashar')},
+	month        = Dec,
+	year         = 2024,
+	note         = {{GNU Parallel is a general parallelizer to run
+	multiple serial command line programs in parallel
+	without changing them.}},
+	publisher    = {Zenodo},
+	doi          = {10.5281/zenodo.14550073},
+	url          = {https://doi.org/10.5281/zenodo.14550073}
 }

motivation.tex

@@ -5,7 +5,7 @@
 
 \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)} 
+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.