Andrew Morgan's Blog

It's a blog

GSoC Weekly Progress Report #4

June 30, 2017 — Andrew Morgan

Hello again! A week has gone by and I've gotten some feedback on the qvm-trust tool introduced in the last post. First off, it's been renamed to qvm-file-trust! It's more descriptive, as the primary application of the tool is manipulation of trust of files, more than anything else. Thanks to Joanna for the suggestion!

In addition to the name change, a number of other changes have been added, as well as a bit of a code refactoring from when I first wrote it. The main bits are:

  • A phrase can now be specified in /etc/qubes/always-open-in-dispvm.phrase, if a file's path contains that phrase, the file is considered untrusted.
  • Now pull and combine results from /etc/qubes/always-open-in-dispvm.list and ~/.config/qubes/always-open-in-dispvm.list to determine list of untrusted folders.
  • Ability to place a '-' in front of a path in the local untrusted folders list in order to override the global's untrusted definition.
  • Add scoped global variables to improve readability.
  • Return codes now reflect the POSIX standard.

The reasoning behind the phrase was the prevent total reliance on xattrs, which isn't supported on all filesystems, such as FAT32, which is still a popular filesystem. Note that the definition of an untrusted file is slightly altered by this. I believe Joanna put it best in the mailing list:

Ideally, I think the evaluation of trustworthiness should be like this:

1. All files are considered [_trusted_] unless we check all the rules below, and
none of them identifies the file as _untrusted_,

2. If the file is under a path which contains pre-defined untrusted string (such
as...  "untrusted", ALWAYS case _insensitive_ match), the file is untrusted, no
matter what xattrs might be saying. E.g. the file might be from some FAT
filesystem attached to the VM via qvm-block or qvm-usb and we still want to
catch it.

3. If the file has xattr saying it's untrusted.

(4. If none of the above, then consider it trusted.)

The separation of the list of untrusted folders paths allows one to define a global list for all AppVMs of a template in the root partition, while simultaneously keeping a local list for each AppVM in the home partition. Additionally, one can override a rule in the global list by placing the same path with a '-' character in front, preventing that path from being considered untrusted.

This is useful in the case of having an untrusted VM that you may be completely fine opening potentially dangerous files in from time to time, as you have nothing of value in it. You can use this with the same template as your personal VM, you need only disable the default rules from the local list in the untrusted VM, and you're set. Props to Marek for this idea!

The error codes have switched around a few times in the last few days. Happy to report they now follow the POSIX standard, and will hopefully be stable now. Thanks for Jean-Philippe for pointing this out! Updated error codes can be found in the documentation. Speaking of which...

Man page

Yes, qvm-file-trust now has a man page!

qvm-file-trust man page

Also viewable in HTML form here.

That's the first man page I've ever written. Shout out to this great resource that made the whole process really painless.

File Managers

We're not finished with them yet. Remember last week where it was determined that no patches of them would be needed? Yeah... turns out that's probably not the case. The new definition of untrusted files above adds some complexity that the current workaround in File Managers does not meet.

Additionally, this definition may change in the future, and instead of trying to find new workarounds for how to emulate that in the file manager, I figure it'd just be simpler for Dolphin and Nautilus to both use qvm-file-trust directly. That way any update to the tool will automatically work in all supported file managers.

By the way, anyone else notice both names 'Dolphin' and 'Nautilus' are water related? Coincidence...?

Testing 1, 2, 3...

I feel that I've hit a pretty solid point in qvm-file-trust in where the purpose of the program and every method is clear, and thus it is a good time to start writing some automated tests to ensure new code doesn't break anything.

As always Marek had some great pointers on how to get started with this.

I'll initially be writing unit tests for qvm-file-trust and some of the other utilities in the repo to ensure everything is working correctly individually. Then, after the file managers have been patched to integrate with qvm-file-trust, and if I have time, I'll do some integration tests that'll run through the GUI and ensure everything is working from both ends.


As always, the code is available here.

That about wraps it up for this week, til next time!

Tags: gsoc-2017, progress-report