66 lines
4.1 KiB
Markdown
66 lines
4.1 KiB
Markdown
|
# File subsystem with process-specific file access control for Linux.
|
||
|
|
## The problem
|
||
|
|
When you run a program on Linux, it can access the same files as the user account that started it, which is usually overly permissive.
|
||
|
|
|
||
|
|
For example, one may write a trojan, that would download all of your photos, documents, personal info, data of other programs, etc. and you wouldn't even have a way of knowing it happened.
|
||
|
|
|
||
|
|
At the same time, you *sometimes* would like *some* programs to have access to *some* of your files, for example if you are applying for the university, you would like your text editor to have access to application form, but you only need it when you are applying for a university, and you only need the editor to access this specific file.
|
||
|
|
|
||
|
|
So you have to somehow control *when* and *which* programs can access *what* file.
|
||
|
|
|
||
|
|
## Existing file access control solutions
|
||
|
|
|
||
|
|
### Linux security modules
|
||
|
|
Kernel modules such as SELinux and AppArmor can certainly enforce rules on *which* programs can access *what* files, which certainly helps. Unfortunately:
|
||
|
|
* They are overcomplicated (especially SELinux).
|
||
|
|
* They have to be compiled into the kernel.
|
||
|
|
* They give permissions forever: you have to reset them manually.
|
||
|
|
|
||
|
|
### Flatpaks, Snaps and similar namespace-based solutions
|
||
|
|
When the programs themselves are isolated from the rest of the OS, it definitely helps to prevent unwanted access to the filesystem. However:
|
||
|
|
|
||
|
|
* To even be able to override the default filesystem access permissions the user needs to use another app (flatseal for example) or to master the CLI tools.
|
||
|
|
* They give permissions forever: you have to revoke them manually.
|
||
|
|
* The program has to be packaged and distributed is a specific way, which is a developer's decision.
|
||
|
|
* **LOTS of apps need access to some files. Because the default permissions are regulated by the developer himself, it is usually easier to give entire filesystem access permissions, rather than select a specific folder that it needs.**
|
||
|
|
|
||
|
|
## My idea to solve the problem
|
||
|
|
Make a program using FUSE that would control processes' access to selected files by freezing the process and letting the user to choose whether to allow the access or not.
|
||
|
|
|
||
|
|
From the point of view of the process files would appear completely normal, so no involvement of the developer is required.
|
||
|
|
|
||
|
|
When a process calls `open()` on a file that our system controls, that process would be frozen. User then uses the system's interface to either allow (and then the file is opened normally), or deny access (and then the `open()` returns `EACCES`).
|
||
|
|
|
||
|
|
Under the hood, the system's daemon would open some other file stored in a hidden directory with restricted "classic" POSIX permissions (I talk more about how those files are protected in the problems section). From now on, these files would be called "source files".
|
||
|
|
|
||
|
|
The program would keep track processes' permissions, and allow repeated access to the same file, to avoid bothering the user excessively.
|
||
|
|
|
||
|
|
Also, because the program is running fully within userspace, it will make it far easier to develop, interface with, install and distribute.
|
||
|
|
|
||
|
|
## Problems
|
||
|
|
|
||
|
|
See `bc-thesis-problems.md` .
|
||
|
|
|
||
|
|
## (Proposed) time plan
|
||
|
|
* before 31.10 - A sort of "security risk assessment" and therefore a review of requirements, since this kind of is a security project.
|
||
|
|
* before 30.11 - Architecture and design.
|
||
|
|
* before 28.01 - Implementation.
|
||
|
|
* before 31.02 - Testing.
|
||
|
|
* before 30.03 - The thesis itself.
|
||
|
|
|
||
|
|
Rest of the time is reserved for unexpected problems.
|
||
|
|
|
||
|
|
Since the "buisness analysis" and requirements are already more than half-ready, I am not including them.
|
||
|
|
|
||
|
|
## Formal specification
|
||
|
|
Name:
|
||
|
|
|
||
|
|
`File subsystem with temporary, process-specific file access control policies for Linux.`
|
||
|
|
|
||
|
|
Goal:
|
||
|
|
|
||
|
|
`Develop and implement a virtual file subsystem that would manage and enforce temporary, process and file specific rules and policies regulated by the user's choice, therefore ensuring greater security by restricting arbitrary file access by processes.`
|
||
|
|
|
||
|
|
[^1]: I haven't found any better information on that topic. The solutions mentioned seem overcomplicated.
|
||
|
|
[^2]: Which is obtained through 22-nd field in /proc/\[pid\]/stat (see `man proc_pid_stat(5)`).
|
||
|
|
[^3]: To the best of my knowledge.
|