d0bdf1ba6e
A lot of stuff happened here. I subdivided the text even more, added the todonotes package.
39 lines
3.3 KiB
TeX
39 lines
3.3 KiB
TeX
\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).
|
|
|
|
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.
|
|
|
|
ICFS 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.
|
|
|
|
\section{Access Control Model}
|
|
|
|
As promised, the access control model of ICFS is trivially simple. It features processes as it's subjects, and files as objects. Whenever a process attempts to open, remove or change POSIX permissions of an existing file that is not a directory or a symbolic link, and this process does not already have access to this file, a dialogue is displayed with three options:
|
|
|
|
\begin{itemize}
|
|
\item \emph{Allow}, that will allow this process and any other process that is started with the same executable to access the file.
|
|
\item \emph{Allow this time}, that will allow the requesting process to access the file.
|
|
\item \emph{Deny}, that will deny all access to the file.
|
|
\end{itemize}
|
|
|
|
\missingfigure[figcolor=white]{ICFS access dialogue}
|
|
|
|
\todo[inline, author={\emph{Draft note}}]{Too much stuff per section? Divide by the issues from previous chapter?}
|
|
|
|
Decisions made in the dialogues are recorded and later reused when processes access files again.
|
|
|
|
On the other hand, if a process attempts to create a file, it is automatically granted permanent access to the file it has created.
|
|
|
|
We chose this model because of its simplicity. Having more options in the dialogue induced heavy choice fatigue of the user, since programs typically open a lot of files throughout their runtime. Even simple text editors open lock and backup files besides the target file. Programs like TeXstudio or programming IDEs open dozens of files simultaneously, since they need all kinds of temporary and configuration files.
|
|
|
|
We chose to give processes unlimited access to directories and symbolic links because they do not contain any data on their own. Having to grant access to every folder on the path to the file is simply too tedious for anyone.
|
|
|
|
The choice to not require access granting for file \emph{creation} is also based in simplicity. If a process can't modify or edit any existing data by creating new files, then there is little use in restricting it. |