A simplified version of the ext4 FileSystem with added security features. This FileSystem is designed for back-ups of highly sensible data and is intended as a defensive measure against Ransomware attacks.
The extra security features are:
- Write protection on file, there are limitations on how you can write on a file;
- Umount protection, the filesystem should be detached only on system shutdown;
- Underlaying block device protection, the user should not be able to interact with the underlying block device after the system is mounted;
- Time limited file removal, file cannot be deleted during their lifespan
- Signature based access control, the file system can deny access to unauthorized process by looking at their address space
Details on the implementation are in the implementation details file.
The disk layout is based on the ext4 FileSystem, the disk is divided in groups and each group has the following organization:
| vfs superblock (only in group 0) |
Group descriptor table (only in group 0) |
Authorized program hashes | Data Block bitmap | Inode Bitamp | Inode Table | Data Blocks |
|---|---|---|---|---|---|---|
| 1 block | 1 block | 10 blocks | 1 block | 1 block | 1024 blocks | 317421 Blocks |
The separation in groups allows us to allocate and find blocks more efficiently and it also makes it esier to avoid fragmentation.
Sizes and limitations are the same of the ext4 FileSystem with a block size of 4 Kb.
The major differences with the ext4 FileSystem are:
- No Reserved GDT blocks, ext4 allocates blocks that can be used to resize the FileSystem if needed, this FileSystem will not have this feature;
- Linear addressing for directories, directory will be treated as linear arrays, not as hash trees;
- No group 0 padding, the ext4 FileSystem leaves 1024 bytes padding at the start of the for boot sectors and other operating system oddities, this FileSytem is not maent to house an OS so this is not needed;
- No journaling, definitely something that should be implemented, but i believe it is out of the scope of the project for now.
- Fixed block size of 4Kb;
- No 32-bit mode for addressing;
TODO - outdated, new features may not work on this versions
This module should work on kernel 5 and 4, different kernel versions are not garanteed to work (and probably won't). It has been tested only on kernel 5.8 and 4.8 so the more likely inteval of working versions is [4.8, 5.8].
The mkfs file does requires the openssl libssl-dev package to be compiled.
Enter the src folder and run: make
The MakeFile will create a VaultFS formatted test image in the current folder name test.img
Default size for the test image is 1GB, to change it edit the "IMAGESIZE" variable in the Makefile.
After this we can insert the module and mount the filesystem with the file on a virtual block device with:
insmod vaultfs.ko
mount -o loop -t vaultfs test.img <directory>
The File System will be mounted with the defult password 1234, to umount we need to call the "umount_ctl" syscall with this password, so run:
user/unlock <directory> 1234
umount <directory>
Go in the tests folder, and to mount run:
sudo su
. ./utils.sh
standard_setup
This will create a temporary image in the /tmp folder and mount the FS to /tmp/mnt, to umount:
sudo su
. ./utils.sh
standard_cleanup
Care, these functions will work only while the PWD is the tests folder.
Currently 2 tests have been implemented:
- Big File Test, creates and copies a "big" file to the FS, used to make sure that file can span multiple groups without problems;
- Extent resize, creates to files and write to them in way to get them to have a non-consecutive block allocation, used to verify that an extent tree will get correctly resized if it doesn't fit anymore in his block;
- Concurrency test, creates multiple files, with many threads writing on each file, checks if we have some concurrency problems;
To run all tests make sure you in the test folder and run:
./run_all_tests <DEBUG> # add DEBUG to see the full output
In the test folder there is an helper python script read_metadata.py to read the filesystem metadata:
> python3.py read_metadata.py
usage: read_metadata.py [-h] {sb,gdt,bm,ino} ...
VaultFS metadata reader
positional arguments:
{sb,gdt,bm,ino}
sb Read VFS superblock
gdt Read VFS GDT info
bm Read bitmap
ino Read inode
options:
-h, --help show this help message and exit
| State | Task | Difficulty |
|---|---|---|
| ✔️ | Add hook to disable mmap on VaultFS fd | 1/5 |
| ✔️ | Add link file opeartion | 2/5 |
| ✔️ | Change inode flags to match state machine in paper | 1/5 |
| ❌ | Create some sort of callback mechanism for the traversing of the extent tree | 5/5 |
| ❌ | GUI file manager does not recognize some folders properly, find out why | ?/5 |
| ❌ | Fix all le/be conversions | 3/5 |
| ❌ | Deny mounting on 32bit systems | 1/5 |
| ❌ | Change the device to work with ioctl | 1/5 |
| ✔️ | Implement concurrency management on the cached gdt | 1/5 |
| ✔️ | I ignored a lot of concurrency problems while programming, need to fix this | 3/5 |
| ✔️ | The search for blocks in the allocation needs to be improved in term of closeness to the other blocks | 4/5 |
| ✔️ | Current makefs is zeroing the whole device, this should not be the default, only an option beacuse its really slow | 2/5 |