Andrew Morgan's Blog

It's a blog

GSoC Weekly Progress Report #3

June 22, 2017 — Andrew Morgan

Good news everyone! The code base has been completely refactored from multiple scripts with duplicated code into one lean python cli tool. All the other scripts simply make use of this now.

Additionally, 90% of the bash in the project has now been replaced with python, which should allow more portability and more maintainable code.

New CLI Tool

This new utility is called qvm-trust, and can be used in the following manner:

$ qvm-trust -h
usage: qvm-trust [-h] [-c] [-t] [-u] [-q] path [path ...]

Set or check file/folder trust levels.

positional arguments:
  path             a folder or file path

optional arguments:
  -h, --help       show this help message and exit
  -c, --check      Check whether a file or folder is trusted
  -t, --trusted    Set files or folders as trusted
  -u, --untrusted  Set files or folders as untrusted
  -q, --quiet      Do not print to stdout

Some example usage includes: setting a file as untrusted:

$ qvm-trust --untrusted ./leaked-documents.pdf

Checking the trusted state of a file:

$ qvm-trust --check ./leaked-documents.pdf
File is untrusted

Setting multiple files and folders as untrusted:

$ qvm-trust --untrusted ~/Downloads ./my-sketchy-file.docx ~/QubesIncoming

Checking trusted state through the return code (useful for scripting):

$ qvm-trust --check ~/Downloads --quiet
$ echo $?

A reference for the return codes is as follows. Additionally I plan to write up a man page with all usage information soon:

Error codes:
    Unable to read extended attributes: -2
    Unable to read an input file: -1
    No errors: 0
    File/Folder is untrusted: 1
    File/Folder is trusted: 2

Nautilus and Dolphin integration

The Nautilus extension and Dolphin service files now make use of this script. This cut down the file size of the Nautilus extension considerably, as well as removed the need for the large bash script that was dedicated specifically to checking trust in Nautilus, as well as the two extensions for Nautilus. Now there is simply one extension that handles both files and folders.

xattr is also no longer a dependency as we now do all the extended file attribute checking and setting through python.

Additionally the ability to mark file-types as untrusted has been removed, as there really wasn't a considerable use case for it and it made implementation more complex than necessary. In the future it could be added, but at the moment there's no real need for it.

However one benefit to its removal is no more complicated check-box UI to navigate through! It's all simply there in the right-click menu:

Nautilus context menu with right click for folders Nautilus context menu with right click for files

There is now a single context menu item for both files and folders.

On the Dolphin side, the check-boxes have similarly been deprecated, however I was unable to find a way to add the sleek icon next to the service menu item as done in Nautilus. Unfortunately there doesn't seem to be a way to change a service's icon based on a script's output, so for now I've settled on a sub-menu which the user can choose whether to mark a file/folder as trusted or untrusted:

Dolphin with right-click sub-menu

Separate menus since Dolphin can't switch icons on the fly.

Also if you didn't already notice, 'Open in DisposableVM' now shows up with a little Qubes logo in the right-click menu of untrusted files!

Qubes logo now shows up for untrusted files

Qubes logo now shows up for untrusted files.

This was achieved with a .desktop file that is called upon when a certain MIME-type is clicked. This was originally the plan for recognizing untrusted files in the file-manager, however it was not considered a viable option as an untrusted file could have any file-type (i.e PDF, TXT, DOCX, etc). It wouldn't make sense to register all of these types to be opened in DisposableVMs, so it was dropped.

That was until we started 'locking' untrusted files to disallow reading by local applications. This had the unintended but incredibly useful side-effect of having file managers set the MIME-type to application/octet-stream. At that point we simply had to register that MIME-type for our custom .desktop file and we were good!

Small bugs/issues

There are still some small roadblocks that still need to be cleared up:

  1. While the functionality in Nautilus is all there, Nautilus doesn't always seem to re-run the file-checking code in our extension. This can cause the wrong icon to appear when right-clicking a file, which is certainly confusing. The correct icon is shown if you click some empty space, then right-click the file again. I feel this is more a Nautilus bug than an issue with our file-checking code. I'll hit up the devs on #nautilus soon and see if I can get some answers.

  2. KDE's Dolphin handles MIME-type checking a bit differently than Nautilus does. For instance, instead of solely checking for MIME-types by reading the contents of the file, it gives the greatest priority to the file extension.

    Dolphin thinks a PDF is a text file, due to its extension

    This is a PDF that has been renamed with the '.txt' extension. Dolphin thinks it is a text file.

    KWrite being suggested instead of qvm-trust

    KWrite is suggested to edit it.

  3. Dolphin doesn't mark untrusted files as a specific file-type, instead it simply says 'unknown':

    Dolphin is confused What could it be?!

    Clicking on 'Create New File Type' does allow us to make new ones called application/x-kdeuser, however even after doing so the file-type is still unknown.

    Actually while writing this I just thought... we could combine 2 and 3 together and just append '.untrusted' to untrusted file types, then register the '.untrusted' file extension with our desktop handler. Hm... will try that right after I post this :)

  4. Dolphin does not allow unreadable files to be opened. It cancels the application launch and presents an 'Access Denied' message. Not entirely sure if there is a way around this outside of a patch. It would be great to find a workaround.

    Dolphin won't let us open unreadable files This file is unreadable, dummy!

    Update: this may not be an issue with the '.untrusted' workaround above. Apparently if the file-type is recognizable it will send it to the application that's registered

  5. The location of the untrusted-folders file. This file keeps track of the folder paths that are untrusted, and is used by the daemon. Even after reading the Qubes Contribution Guidelines I'm still not sure where to put this. /usr/share/qubes seems to be the apt location but there's not much in there already. Marek?

Going Forward

We're currently heading into week 2 of 4 of what was supposed to be patching the file managers, however now that it seems that's no longer necessary, we're pretty much ahead of schedule! After Dolphin is fixed up, I'll create a daemon to monitor untrusted folders and their contents. If a new file is placed or created inside them, they'll instantly be marked as untrusted.

After that is unit tests and documentation cleanup. Pretty standard stuff.

As always the code is available here.

Anyways, that's about it for this week. Til next time!

Tags: gsoc-2017, progress-report