Important

If you need the version that correponds to the thesis attachment, go here. This version contains corrections of errors that the opponent brought to my attention.

Motivation

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 file system layer which delegates the decision to allow or deny access to a file system object by a specific process to the user.

Goals

Analyze the problem and design a solution
Implement the solution using the FUSE framework
Test the solution and demonstrate its benefits

Building

Install dependencies
- libfuse3
  - Debian: sudo apt install fuse3 libfuse3-dev
- SQLite3
  - Debian: sudo apt install libsqlite3-dev
- GTK4, libadwaita
  - Debian: sudo apt install libgtk-4-dev libadwaita-1-dev
- Build tools
  - Debian: sudo apt install gcc make pkg-config
Build using make:
- In the project directory: make
- Add DEBUG=1 to show more compiler warnings.
- Add TEST=1 to also test the program.
- Add DIALOGUE=0 to not compile the dialogue program.
Resulting binaries should appear in the build directory.

Installation

make install
Uninstall with make uninstall

Usage

Usage: icfs <FUSE arguments> [target directory] [path to the permanent permissions database] <ICFS arguments>
 --no-grant-on-create - do not give any access permissions on file creation(incompatible with --perm-on-create)
 --perm-on-create - automatically give permanent access permission to files a process creates (incompatible with --no-grant-on-create)

The filesystem will be mounted over the target directory, and ask user permission every time a file in that directory is opened. We highly recommend adding -o default_permissions to increase performance and add an additional security layer. If you have installed icfs along with /etc/icfs folder, you can create your permanent permission databases in this folder (you might want to do this, if your home folder does not have the "execute" permission for other users).

Development build

Execute this command in the root directory of this project:

env PATH="$(realpath ./build):$PATH" build/icfs <FUSE arguments> [target directory] [path to permanent permission database]

The env PATH="$(realpath ./build):$PATH" adds the access dialogue program to PATH, allowing ICFS to call it seamlessly.

Running tests

ICFS includes a testing script in the test directory.

You can run it from test directory by running:

./test.bash

All testing artifacts will be available in the appropriate folders after run. To test setuid capabilities too (from test directory!!!):

./test.bash --setuid

You can also test performance by adding --performance (from test directory!!!):

./test.bash --performance

Important: flags cannot be combined together (e.g. you can't add --performance and --setuid)

Docs

Credit

Student: Fedir Kovalov

Supervisor: RNDr. Jaroslav Janáček, PhD.