Problems

Keeping track of running processes

Since we can't simply be notified about random process's termination¹, the question arises: how to keep track of the processes in the permission table? If we don't delete a permission table entry exactly before the process finishes, another process, intentionally or not, gets the same PID, it would gain unauthorized access to files.

The solution I offer involves writing down process's start time:

Permission table will consist of entries (pid, starttime, permission), where pid is the process's PID, starttime is the process's start time and permission is the type of access the process is allowed (e.g. to which files).
When the process opens a file, search through the table.
- If an entry with the correct PID was found:
  - If $starttime_{table} < starttime_{actual}$², delete all the entries with that PID and file a permission request to the user -- the process that requested access is not the same because it has started after the original process who had this permission(and because their PIDs match, the original process had to end before this could start).
  - Otherwise:
    - If the permission matches the request, open the file.
    - Otherwise file a new permission request.
- Otherwise file a new permission request.

This approach should make "permission hijacking" practically impossible, as it would take a considerable amount of time just to approve the permission. Even if our permissions could be approved instantly it would still take a few scheduler cycles to execute the original program, so the new ones must have a later start time.

This approach still has an issue: the table would be hoarded with old permissions, and therefore waste memory. This might be mitigated by regular cleanups (e.g. every time you create a new permission, check if the oldest one's process is still running)

Another issue might be speed, because all of the table lookups take linear time. But considering that file opening isn't exactly a time-critical operation and that the table could be sorted by PID, it does not seem to be that big of an issue.

FUSE issues

As mentioned in the initial idea, the source files have to be protected from external access in some way.

Here I can see three solutions:

Encrypting source files.
Running our virtual filesystem daemon as a special user, and making all our source files only accessible to this special user, therefore processes would have no permissions to access the source files.
Use some LSM's MAC policy to deny access to source files to any process except our daemon.

The first solution would definitely be preferable from the standpoint of compatibility, as it requires no special configuration, and because it mitigates the issue the best, as the attacker has to get encryption keys from the memory. Moreover, it could allow us to deny access for processes running as root³. However, implementing encryption seems to be way out of scope of this project.

The second solution seems to work well in theory. There are some specific details to be clarified about it's implementation, but generally it seems to work out.

Although the third solution looks like exactly what we are looking for, but it requires a kernel module that enforces MAC policies. Even though those modules are common on most distros, they are pretty different from each other, and I think their usage should be limited to being an additional layer on top of the second solution.

User interface

From the description of the software, it remains unclear what type of user interaction design is appropriate. Do we make a CLI? GUI?

I propose to deal with it like the Transmission did³ -- create the backend with an integrated CLI first, and then make GUI wrapper in GTK after (if there would be time, of course :) ).

Programs with CLI

Programs that are run via shell can have an execution time of a fraction of a second, which means you would have to re-allow the access for them every time you run them. My solution is to give an option to set permissions for specific sessions, so that every command run from a specific terminal window would have the same permissions. Then the permission table would be populated with the session process's data (e.g. the shell), or maybe this would necessitate a separate table just for the sessions. That might also imply a creation of two CLI tools:

sprequest [PERM] -- request a certain permission for the session
spdrop -- drop all permissions given to the session

Too many files...

It would be annoying to go and allow access for each program every time one of them opens a new file. For example, if the file subsystem looks like this:

Documents/
| Work/
| | horalky_secret_recipe.pdf
| | colleagues.csv
| Notes/
| | set_theory.md
| | Peano_axioms.md
| | ...
| | Cantor_theorem.md

If I want to view my notes, I would want allow my markdown editor the access to all the files in the Documents/Notes folder to make links work, but when I want to find a name of my colleague, I would like to only give the permission to the Documents/Work/colleagues.csv file. The solution is obvious: to give an option for the user to give permissions for the entire folder, not just a specific file.

Other

Threads (not that big of a problem, but a complication nevertheless).
All of the permissions get reset after the process is ended, which is annoying. Perhaps it would be possible to implement permanent permissions through identifying programs by their executables' hashes/paths, but updates almost certainly make that impossible (unless we are modifying a package manager, which is clearly out of scope of this project).

Another issue, severity of which I can't assess properly, is whether this idea fits the Informatics degree, as it does not seem to be as much of an experimental or "theoretical" idea. In my opinion it sill holds enough water to entertain the possibility though.

I haven't found any better information on that topic. The solutions mentioned seem overcomplicated. ↩︎
Which is obtained through 22-nd field in /proc/[pid]/stat (see man proc_pid_stat(5)). ↩︎
To the best of my knowledge. ↩︎

6.4 KiB Raw Blame History