Andrew Morgan's Blog

It's a blog

GSoC Weekly Progress Report #7

July 24, 2017 — Andrew Morgan

Hello and welcome to another weekly report! Well, this one may have been bi-weekly, but at least we're set to be back on schedule now.

Since the last report a few exciting things have been completed. This includes packaging of qvm-file-trust as an installable python package, a functioning qubes-trust-daemon, and some strong headway on patching Nautilus!

So without further ado, let's get into it:

Pretty Python Packaging

qvm-file-trust has been moved from the project's root directory into its own directory and its own python package. This has the benefit of cleaning up the root folder a bit, but more importantly allowing for proper importing into other python scripts.

Tests have been refactored to no longer use the hacky method of importing qvm-file-trust and instead import the new qubesfiletrust package directly.

Finally, installing the python package and all the other scripts can now be achieved through the use of a Makefile. Simply sudo make install and you're done!

Daemon Challenges

Coming from python back to C++ took a moment of re-adjustment as I had started to get used to the conveniences that python provides. There is however no doubt that the tradeoff of what C and C++ offer in terms of performance are worth the drop in comfort.

What was interesting was that even after deciding to switch qubes-trust-daemon from C to C++, a majority of the code that went into programming the daemon was C compatible. Low-level libraries like inotify are written for C, and one must interact with them with C-like components such as null-terminated character arrays as opposed to C++'s std strings. In this sense, C++'s ability to handle nearly all C code is thus incredibly useful.

After a few days I became comfortable working within these two languages. C offers necessary power and speed, while C++ offers many convenient classes and functions that I was able to make use of.

So after all that, here's the story on what is completed with qubes-trust-daemon and what still needs to be done:

What's done:

  • Grab a list of untrusted folders from the global and local list
  • Place an inotify directory watch on those folders and subfolders and listen to various file change events
  • Act on events such as items being created or moved inside of untrusted folders. Upon catching one of these events, we either watch the new folder for further events, or if it is a file, mark that file as untrusted
  • Handle files being deleted or moved out of watched directories

What's still to do:

  • Proper error reporting
  • Testing

Currently, the list of untrusted folders are grabbed and sorted by the daemon directly and then passed to other functions. I am considering adding the ability to export the list that qvm-file-trust creates as a line-by-line list to stdout and having the daemon capturing that instead.

The upside to this is that there is only one implementation of parsing and sorting the lists and it is written in a language where there are less likely to be parsing errors by the programmer. The downside will be that you must start up an instance of qvm-file-trust to perform this action, but as it will only be done once per initialization of the daemon, the cost is mostly negligible.

As it stands on my i7-4810MQ, only 6.7% of the VM's CPU (2 out of my 4 cores) is used as a couple tens of thousand files are being marked as untrusted on startup and on moving a large folder in. That CPU usage is well within reasonable levels, especially on such a large operation. That is a win in my book.

Nautilus

The patch for Nautilus is finally getting going! After some hiccups with Nautilus' build process, I've now switched to GNOME Builder for the compilation and run management of Nautilus. Builder provides a much cleaner experience when building and compiling, and after only hearing about it here and there, it was exciting to finally download and try it out.

After a couple hiccups with importing the Nautilus code and checking out the correct branch (gnome-3-22 in this case) with the help of some fine folks on #gnome-builder, Nautilus was building and launching as expected:

Nautilus built and running from Builder Nautilus built and running from Builder

The other advantage GNOME Builder holds is its ability to build all projects as flatpaks. This makes it much easier to share testing builds of Nautilus without asking people to install Nautilus' horrible list of dependencies, and instead just run a single command to start it up!

In addition to Nautilus, GNOME Builder is also helping me with patching nautilus-python, which are the python bindings that allow extensions written in python to interact with Nautilus' C API.

This folder houses the definitions of functions that can be referenced in nautilus-python extensions. Nautilus' maintainer, Carlos Soriano, also kindly pointed out where these methods connect to Nautilus itself, which turns out to be here.

The typical workflow in a nautilus-python extension is to define a function that corresponds to the data or action you desire, then return some data based on some logic you have in your extension. My plan is to create another function here that will be called when a file is determined to be opened. The file will then be opened depending on whether the extension returns a True or a False.

A new DisposableVM with the file in question can be launched from within the extension, so there is no need for any Qubes-specific code to go into this patch.

User UX

In other news, in addition to the Dolphin Folder Color that allows you to set the color of a folder from an extension, I have now come across a similar offering for Nautilus, titled simply Folder Color (code here).

With the ability to now mark untrusted folders with a color (likely red), and with Nautilus and Dolphin already adding an icon for untrusted files (due to their unreadable nature), I no longer see any reason to add additional icons on top of this. After a few rounds of testing, seeing many 'warning' and 'lock' icons on files got a bit repetitive anyways :)

Conclusion

Phew, that was quite a few things to talk about. At this point I'm going to be devoting the majority of my time to get Nautilus' patch functional. Once we have a complete GUI + cli tool + daemon working together we can more easily get a picture of how to test and tweak the overall flow of the tool.

I'll also be providing flatpak's of Nautilus for easier testing, which will most certainly be appreciated once they are available!

Anyways, that is all for now. As always, you can find the code here.

Have a wonderful day!

Tags: gsoc-2017, progress-report