fedir/ICFS-thesis
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Added existing files.

Browse Source
This commit is contained in:
BritishTeapot 2025-04-09 12:16:10 +02:00
parent ab78512d8a
commit 7be91f3224
11 changed files with 596 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Makefile Normal file
View File

@ -0,0 +1,15 @@
# nechajte iba jeden z main.pdf a main-en.pdf
all: main-en.pdf
main.pdf: main.tex *.tex *.bib images/*
pdflatex main
bibtex main
pdflatex main
pdflatex main
main-en.pdf: main-en.tex *.tex *.bib images/*
pdflatex main-en
bibtex main-en
pdflatex main-en
pdflatex main-en

20
approach.tex Normal file
View File

@ -0,0 +1,20 @@
\chapter{Interactively Controlled File System}
In this section we present the solution developed as a part of this thesis, named \emph{Interactively Controlled File System} (or ICFS for short).
\section{Features}
ICFS is a filesystem layer that gives user direct command over its access control. Instead of relying on static policies or rules, it prompts the user for the access control decision via graphical interface. When a process tries to open a file, an overlay is displayed, and three options are given: to deny, temporarily allow, or forever allow access to a file.
It is user-friendly and trivially easy to use. It does not introduce any new terminology or complex access control management strategies. The graphical interface is intuitive and self-explanatory. ICFS is configured on the fly: as programs request access, the user's decisions are recorded and later reused. There is no need for any configuration besides installation and choosing a directory to control. It operates on the level of individual processes and files, ensuring high granularity.
\iffalse
At the same time, it allows for broader, more general rules, which helps to reduce the choice fatigue of the user.
\fi
It is backwards compatible: ICFS overrides the regular system call interface using FUSE framework, which means that any software that wishes to use the files ICFS protects has to respect it's policies. Its interactivity combined with the ability to only grant permissions for the lifetime of a specific process makes proxy attacks very difficult to go unnoticed.
\subsection{Access Control Model}

5
conclusion.tex Normal file
View File

@ -0,0 +1,5 @@
\chapter*{Conclusion} % chapter* je necislovana kapitola
\addcontentsline{toc}{chapter}{Conclusion} % rucne pridanie do obsahu
\markboth{Conclusion}{Conclusion} % vyriesenie hlaviciek
In conclusion, the overall value and benefits of the solution is discussed(reiterated \verb|:)|).

15
evaluation.tex Normal file
View File

@ -0,0 +1,15 @@
\chapter{Evaluation}
In this chapter presents the method of evaluating the solution is presented, and the found qualities of the solution are discussed.
Specifically this includes:
\begin{itemize}
\item ,,Does the solution actually solve the problem?''
\item Interoperability with other software: does using this fs break other programs, like whether it interferes with programs using auxiliary files, usability of terminal programs (\verb|grep| is a particularly nasty one for this specific project).
\item Performance and overhead.
\item Security considerations.
\end{itemize}
\section{Known Issues}
This section outlines the known issues with the solution and evaluates their relevancy/severity.

BIN
images/zadanie-en.pdf Normal file
View File

Binary file not shown.

BIN
images/zadanie.pdf Normal file
View File

Binary file not shown.

3
implementation.tex Normal file
View File

@ -0,0 +1,3 @@
\chapter{Implementation}
This chapter describes the software design and architecture, and the way that they help to solve the problem. Importantly, the design elements must have at least some justification in this section.

27
intro.tex Normal file
View File

@ -0,0 +1,27 @@
\chapter*{Introduction} % chapter* je necislovana kapitola
\addcontentsline{toc}{chapter}{Introduction} % rucne pridanie do obsahu
\markboth{Introduction}{Introduction} % vyriesenie hlaviciek
\iffalse
The introduction contains:
\begin{itemize}
\item the state of things
\item The problem
\item Existing solutions and why they don't work
\item our approach
\item the layout of the thesis
\end{itemize}
\fi
In modern operating systems, access control mechanisms are fundamental to ensuring the confidentiality, integrity, and availability of system resources. These mechanisms dictate how users and processes interact with system objects such as files, directories, and devices. However, traditional access control models, such as the discretionary access control (DAC) employed by Linux and other Unix-like systems, operate under the assumption that all processes running under the same user account should have the same level of access to system resources. While this simplifies user management and permissions, it can introduce significant security risks.
The problem arises when a process or application running under a user's account becomes compromised. In such cases, the malicious code or exploit can leverage the user's existing permissions to access or modify sensitive data, potentially leading to data breaches or other security incidents. This fundamental limitation of traditional access control mechanisms underscores the need for a more granular and dynamic approach to file system access control.
Over the years, various mandatory access control (MAC) mechanisms, such as SELinux (Security-Enhanced Linux) and AppArmor have been developed to address these limitations. These systems enforce access control policies at a more granular level, often based on labels or rules defined by system administrators. While these mechanisms are effective in certain scenarios, they are generally complex to configure and require significant expertise to maintain. As a result, they are rarely adopted in common user-oriented environments, where simplicity and ease of use are paramount.
In this thesis we introduce our approach to file system access control that empowers users to make real-time decisions about which processes or applications should have access to specific file system objects. By integrating an interactive decision-making layer into the file system, this solution aims to bridge the gap between the security benefits of MAC mechanisms and the simplicity required for widespread adoption. The proposed system delegates access control decisions to the user, enabling them to grant or deny access to individual processes or applications on a per-object basis. This approach not only enhances security but also maintains the flexibility and usability that are critical for user-oriented systems.
The rest of this thesis is organised as follows: Chapter 1 provides a review of existing access control mechanisms and their limitations. Chapter 2 outlines the design objectives, architecture, and the interactive component of the proposed file system layer. Chapter 3 describes the implementation process, including the tools and techniques used to develop the system. Chapter 4 presents experimental results and evaluates the performance and security benefits of the proposed solution. Finally, in Chapter 5 we describe some limitations of the proposed solution, and discuss the potential for further development.

80
literatura.bib Normal file
View File

@ -0,0 +1,80 @@
@article{FGACFS,
doi = {https://doi.org/10.1016/j.cose.2019.101632},
keywords = {Access control, Folder sharing, ACL, Filesystems, FUSE, Userspace filesystem},
pages = {101632},
year = {2020},
url = {https://www.sciencedirect.com/science/article/pii/S0167404819301798},
title = {FGACFS: A fine-grained access control for *nix userspace file system},
journal = {Computers \& Security},
author = {Nikita Yu. Lovyagin and George A. Chernishev and Kirill K. Smirnov and Roman Yu. Dayneko},
volume = {88},
abstract = {In this paper we present FGACFS — a fine-grained access control file system designed for creating and administering directories with shared access in the *nix operating system family. The proposed access control model extends POSIX ACLs. Its essential features are: 1) an extensive list of enforceable permissions, 2) separating file and directory permissions, 3) two different mechanisms of permission inheritance — one for classic inheritance and one for copying permissions for newly-created objects. In overall, there are 19 file and 29 directory permission types. These permissions are designed to be implemented in a single tool and to allow control of both system users and programs simultaneously. To evaluate our approach, we have developed a software implementation based on this model. FGACFS is a userspace file system that was created by implementing the FUSE interface. Our file system is independent of underlying network and on-disk file systems. In our experiments we have evaluated two different approaches for storing permissions and a single permission caching scheme that we have developed to speed up operations. The conducted performance tests show the efficiency of our approach and demonstrate that our solution is ready to be deployed and used at least in small workgroups.},
issn = {0167-4048},
}
@article{MCINTOSH,
issn = {0167-4048},
abstract = {Ransomware attacks are often catastrophic, yet existing reactive and preventative measures could only partially mitigate ransomware damage, often not in a timely manner, and often cannot prevent the novel attack vectors. Many of them were program-centric or data-centric and did not take into consideration user intention or consent. In this paper, we advocate for a dynamic approach of detecting ransomware-like behaviors by proposing a user-centric access control framework, which collects security indicators from the Operating System (OS) to deduct security metrics, compute security indicators and estimate security positions, to dynamically make access control assessments on file access requests. To demonstrate its applicability, we effectuated the principles of User-Driven Access Control (UDAC) for user intention (the goal of a user operation) and Content-Based Isolation (CBI) for user consent (the acceptance of the consequence of a user operation), and developed a proof-of-concept prototype on Windows desktop platforms. It collected information that could reveal the application identity, behavior and the OS environmental factor, before assessing whether an access request to the file system violated the principles of UDAC or CBI. Our prototype was able to raise early warnings on both attacks by real and simulated ransomware of novel vectors.},
year = {2021},
keywords = {Access control, Ransomware, Malware, File system, User intention, User Consent},
journal = {Computers \& Security},
title = {Dynamic user-centric access control for detection of ransomware attacks},
volume = {111},
url = {https://www.sciencedirect.com/science/article/pii/S0167404821002856},
doi = {https://doi.org/10.1016/j.cose.2021.102461},
pages = {102461},
author = {Timothy McIntosh and A.S.M. Kayes and Yi-Ping Phoebe Chen and Alex Ng and Paul Watters},
}
@article{BIGSURSTAT,
publisher = {Association for Computing Machinery},
title = {A Survey on Empirical Security Analysis of Access-control Systems: A Real-world Perspective},
articleno = {123},
month = {December},
abstract = {There any many different access-control systems, yet a commonality is that they provide flexible mechanisms to enforce different access levels. Their importance in organisations to adequately restrict resources, coupled with their use in a dynamic environment, mandates the need to routinely perform policy analysis. The aim of performing analysis is often to identify potential problematic permissions, which have the potential to be exploited and could result in data theft and unintended modification. There is a vast body of published literature on analysing access-control systems, yet as performing analysis has a strong end-user motivation and is grounded in security challenges faced in real-world systems, it is important to understand how research is developing, what are the common themes of interest, and to identify key challenges that should be addressed in future work. To the best of the authors’ knowledge, no survey has been performed to gain an understanding of empirical access-control analysis, focussing on how techniques are evaluated and how they align to the needs of real-world analysis tasks. This article provides a systematic literature review, identifying and summarising key works. Key findings are identified and discussed as areas of future work.},
year = {2022},
url = {https://doi.org/10.1145/3533703},
issn = {0360-0300},
number = {6},
volume = {55},
journal = {ACM Comput. Surv.},
issue_date = {June 2023},
address = {New York, NY, USA},
numpages = {28},
keywords = {Access control, security policy, analysis, empirical analysis},
author = {Parkinson, Simon and Khan, Saad},
doi = {10.1145/3533703},
}
@inproceedings{DunlapMAC,
doi = {10.1145/3532105.3535016},
url = {https://doi.org/10.1145/3532105.3535016},
title = {A Study of Application Sandbox Policies in Linux},
booktitle = {Proceedings of the 27th ACM on Symposium on Access Control Models and Technologies},
location = {New York, NY, USA},
address = {New York, NY, USA},
abstract = {Desktop operating systems, including macOS, Windows 10, and Linux, are adopting the application-based security model pervasive in mobile platforms. In Linux, this transition is part of the movement towards two distribution-independent application platforms: Flatpak and Snap. This paper provides the first analysis of sandbox policies defined for Flatpak and Snap applications, covering 283 applications contained in both platforms. First, we find that 90.1\% of Snaps and 58.3\% of Flatpak applications studied are contained by tamperproof sandboxes. Further, we find evidence that package maintainers actively attempt to define least-privilege application policies. However, defining policy is difficult and error-prone. When studying the set of matching applications that appear in both Flatpak and Snap app stores, we frequently found policy mismatches: e.g., the Flatpak version has a broad privilege (e.g., file access) that the Snap version does not, or vice versa. This work provides confidence that Flatpak and Snap improve Linux platform security while highlighting opportunities for improvement.},
pages = {19–30},
numpages = {12},
year = {2022},
isbn = {9781450393577},
publisher = {Association for Computing Machinery},
author = {Dunlap, Trevor and Enck, William and Reaves, Bradley},
keywords = {sandbox policy, access control, Linux applications},
series = {SACMAT '22},
}
@online{FLATPAK,
title = {FlatPak - The future of application distribution on Linux.},
url = {https://flatpak.org/},
}
@online{SNAP,
title = {Snapcraft - Snaps are universal Linux packages.},
url = {https://snapcraft.io/},
}
@online{APPIMAGE,
title = {AppImage | Linux apps that run anywhere },
url = {https://flatpak.org/},
}

336
main-en.tex Normal file
View File

@ -0,0 +1,336 @@
\documentclass[12pt, twoside]{book}
%\documentclass[12pt, oneside]{book} % jednostranna tlac
%spravne nastavenie okrajov
\usepackage[a4paper,top=2.5cm,bottom=2.5cm,left=3.5cm,right=2cm]{geometry}
%zapnutie fontov pre UTF8 kodovanie
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
%nice code
\usepackage{minted}
%zapnutie slovenskeho delenia slov
%a automatickych nadpisov ako Obsah, Obrázok a pod. v slovencine
%\usepackage[slovak]{babel} % vypnite pre prace v anglictine!
%nastavenie riadkovania podla smernice
\linespread{1.25} % hodnota 1.25 by mala zodpovedat 1.5 riadkovaniu
% balicek na vkladanie zdrojoveho kodu
\usepackage{listings}
% ukazky kodu su cislovane ako Listing 1,2,...
% tu je Listing zmenene na Algoritmus 1,2,...
\renewcommand{\lstlistingname}{Algorithm}
% nastavenia balicka listings
% mozete pridat aj language=...
% na nastavenie najcastejsie pouzivaneho prog. jazyka
% takisto sa da zapnut cislovanie riadkov
\lstset{frame=lines}
% balicek na vkladanie obrazkov
\usepackage{graphicx}
% balicek na vkladanie celych pdf dokumentov, tu zadanie
\usepackage{pdfpages}
% balicek na spravne formatovanie URL
\usepackage{url}
% balicek na hyperlinky v ramci dokumentu
% zrusime farebne ramiky okolo liniek aby pdf
% vyzeralo rovnako ako tlacena verzia
\usepackage[hidelinks,breaklinks]{hyperref}
% -------------------
% --- REMOVE BEFORE PUBLISHING
% -------------------
% Big "draft" watermark on the side.
\usepackage{lipsum}
\usepackage{background}
\backgroundsetup{
position=current page.east,
angle=-90,
nodeanchor=east,
vshift=-5mm,
opacity=1,
scale=3,
contents=Draft
}
% -------------------
% --- Definicia zakladnych pojmov
% --- Vyplnte podla vasho zadania, rok ma byt rok odovzdania
% -------------------
\def\mfrok{2024}
\def\mfnazov{Filesystem with Interactive Access Control for Linux}
\def\mftyp{Bachelor Thesis}
\def\mfautor{Fedir Kovalov}
\def\mfskolitel{RNDr. Jaroslav Janáček, PhD.}
%ak mate konzultanta, odkomentujte aj jeho meno na titulnom liste
\def\mfkonzultant{tit. Meno Priezvisko, tit. }
\def\mfmiesto{Bratislava, \mfrok}
% študenti BIN a DAV odkomentujú príslušnú dvojicu riadkov
\def\mfodbor{Computer Science}
\def\program{Computer Science }
% pre BIN:
%\def\mfodbor{Computer Science and Biology}
%\def\program{ Bioinformatics }
% pre DAV:
%\def\mfodbor{Computer Science and Mathematics}
%\def\program{ Data Science }
% Ak je školiteľ z FMFI, uvádzate katedru školiteľa, zrejme by mala byť aj na zadaní z AIS2
% Ak máte externého školiteľa, uvádzajte Katedru informatiky
\def\mfpracovisko{ Department of Computer Science }
\begin{document}
\frontmatter
\pagestyle{empty}
% -------------------
% --- Obalka ------
% -------------------
\begin{center}
\sc\large
Comenius University in Bratislava\\
Faculty of Mathematics, Physics and Informatics
\vfill
{\LARGE\mfnazov}\\
\mftyp
\end{center}
\vfill
{\sc\large
\noindent \mfrok\\
\mfautor
}
\cleardoublepage
% --- koniec obalky ----
% -------------------
% --- Titulný list
% -------------------
\noindent
\begin{center}
\sc
\large
Comenius University in Bratislava\\
Faculty of Mathematics, Physics and Informatics
\vfill
{\LARGE\mfnazov}\\
\mftyp
\end{center}
\vfill
\noindent
\begin{tabular}{ll}
Study Programme: & \program \\
Field of Study: & \mfodbor \\
Department: & \mfpracovisko \\
Supervisor: & \mfskolitel \\
% Consultant: & \mfkonzultant \\
\end{tabular}
\vfill
\noindent \mfmiesto\\
\mfautor
\cleardoublepage
% --- Koniec titulnej strany
% -------------------
% --- Zadanie z AIS
% -------------------
% v tlačenej verzii s podpismi zainteresovaných osôb.
% v elektronickej verzii sa zverejňuje zadanie bez podpisov
% v pracach v anglictine anglicke aj slovenske zadanie
\newpage
\setcounter{page}{3}
\includepdf{images/zadanie.pdf}
\includepdf{images/zadanie-en.pdf}
% --- Koniec zadania
% -------------------
% Poďakovanie - nepovinné
% -------------------
%\newpage
%\pagestyle{plain}
%~
%\vfill
%{\bf Acknowledgments:} Tu môžete poďakovať školiteľovi, prípadne
%ďalším osobám, ktoré vám s prácou nejako pomohli, poradili,
%poskytli dáta a podobne.
% --- Koniec poďakovania
% -------------------
% Abstrakt - Slovensky
% -------------------
\newpage
\section*{Abstrakt}
Tradičné mechanizmy riadenia prístupu v operačných systémoch povoľujú
rovnakú úroveň prístupu všetkým procesom bežiacim v mene toho istého
používateľa. Toto typicky umožňuje škodlivým procesom čítať a/alebo
modifikovať všetky údaje prístupné používateľovi, ktorý spustil zraniteľnú
aplikáciu. Dá sa to riešiť použitím rôznych mechanizmov povinného riadenia
prístupu, no tieto sú často náročné na konfiguráciu a zriedkavo sa používajú
v bežných scenároch orientovaných na používateľa. Táto práca sa zameriava
na návrh a implementáciu vrstvy súborového systému, ktorá rozhodnutie
povoliť alebo zakázať prístup k objektu súborového systému konkrétnym
procesom deleguje na používateľa.
\paragraph*{Kľúčové slová:} riadenie prístupu, súborové systémy, FUSE, súhlas používateľa, najmenšie oprávnenie, oprávnenia, udeľovanie oprávnení, riadenie prístupu riadené používateľom.
% --- Koniec Abstrakt - Slovensky
% -------------------
% --- Abstrakt - Anglicky
% -------------------
\newpage
\section*{Abstract}
Traditional access control mechanisms in operating systems allow the same
level of access to all processes running on behalf of the same user. This typically
enables malicious processes to read and/or modify all data accessible to the
user running a vulnerable application. It can be dealt using various mandatory
access control mechanisms, but these are often complicated to configure and are
rarely used in common user oriented scenarios. This thesis focuses on design
and implementation of a filesystem layer which delegates the decision to allow
or deny access to a filesystem object by a specific process to the user.
\paragraph*{Keywords:} access control, filesystems, FUSE, user consent, least-privilege, permissions, permission granting, user-driven access control.
% --- Koniec Abstrakt - Anglicky
% -------------------
% --- Predhovor - v informatike sa zvacsa nepouziva
% -------------------
%\newpage
%
%
%\chapter*{Preface} %
%
%Predhovor je všeobecná informácia o práci, obsahuje hlavnú charakteristiku práce
%a okolnosti jej vzniku. Autor zdôvodní výber témy, stručne informuje o cieľoch
%a význame práce, spomenie domáci a zahraničný kontext, komu je práca určená,
%použité metódy, stav poznania; autor stručne charakterizuje svoj prístup a svoje
%hľadisko.
%
% --- Koniec Predhovor
% -------------------
% --- Obsah
% -------------------
\cleardoublepage
\tableofcontents
% --- Koniec Obsahu
% -------------------
% --- Zoznamy tabuliek, obrázkov - nepovinne
% -------------------
\newpage
\listoffigures
\listoftables
% --- Koniec Zoznamov
\mainmatter
\pagestyle{headings}
\input intro.tex
\input accesscontrol.tex
\input motivation.tex
\input approach.tex
\input implementation.tex
\input evaluation.tex
\input conclusion.tex
%\input zaver.tex
% -------------------
% --- Bibliografia
% -------------------
\newpage
\backmatter
\thispagestyle{empty}
\clearpage
\bibliographystyle{plain}
\bibliography{literatura}
%Prípadne môžete napísať literatúru priamo tu
%\begin{thebibliography}{5}
%\bibitem{br1} MOLINA H. G. - ULLMAN J. D. - WIDOM J., 2002, Database Systems, Upper Saddle River : Prentice-Hall, 2002, 1119 s., Pearson International edition, 0-13-098043-9
%\bibitem{br2} MOLINA H. G. - ULLMAN J. D. - WIDOM J., 2000 , Databasse System implementation, New Jersey : Prentice-Hall, 2000, 653s., ???
%\bibitem{br3} ULLMAN J. D. - WIDOM J., 1997, A First Course in Database Systems, New Jersey : Prentice-Hall, 1997, 470s.,
%\bibitem{br4} PREFUSE, 2007, The Prefuse visualization toolkit, [online] Dostupné na internete: <http://prefuse.org/>
%\bibitem{br5} PREFUSE Forum, Sourceforge - Prefuse Forum, [online] Dostupné na internete: <http://sourceforge.net/projects/prefuse/>
%\end{thebibliography}
%---koniec Referencii
% -------------------
%--- Prilohy---
% -------------------
%Nepovinná časť prílohy obsahuje materiály, ktoré neboli zaradené priamo do textu. Každá príloha sa začína na novej strane.
%Zoznam príloh je súčasťou obsahu.
%
%\input appendixA.tex
%\input appendixB.tex
\end{document}

95
motivation.tex Normal file
View File

@ -0,0 +1,95 @@
\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.
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
Although this kind of access control solutions has been proven to be helpful in multi-user environments, it is insufficient to protect against an attack performed by a process initiated by the same user.
In such case,
Moreover, none of the manipulations with the data will be immediately apparent to the user. Copying might as well be totally undetectable, if no access logs are being recorded.
As we have demonstrated, the possibilities for data manipulation are virtually limitless when a process operates under the same user account that owns the targeted data. Of course, the malicious program does not necessarily have to be a shell script; any process with the same user privileges as the files it attempts to access can achieve similar outcomes. This scenario opens the door to a wide array of attacks, including data exfiltration and ransomware.
\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| 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