-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Wed, Jun 21, 2017 at 11:15:30PM -0700, Andrew Morgan wrote: > Hey everybody, another progress report for ya. > > As always, you can find the report with screenshots here: > https://blog.amorgan.xyz/gsoc-weekly-progress-report-3.html > > Otherwise the text-only version is reproduced below: > > --- > > 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 $? > 2 > > 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
IMO --check should return 0 for trusted files. This way it would be possible to use `if qvm-trust --check ...; then` (or negated with `!`). Also consider making --check default action. As for the code: - use main() function called `if __name__ == '__main__'`, instead of putting the code directly there - it will ease writing unit tests later, and possibly reusing the code by simply importing this script - use try ... finally syntax to restore file permissions, even if xattr read fails; and more important (also achievable by try/finally): keep restoring file permissions in the same function that change it in the first place (try/finally works even for exit() call, as in python it just raise SystemExit exception) An idea: mark folder untrusted also using xattr. Then it will be immune to folder rename. And checking file inside would require "just" checking directories up in the tree. This does not replace the need for some daemon to mark individual files inside as untrusted (when appears), but may (or may not) make things easier. > # 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: > > [Screenshot] Nautilus context menu with right click for folders Nautilus > context menu with right click for files Nice! > 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: > > [Screenshot] 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! > > [Screenshot] 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: > > 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. > > 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. > > [Screenshot] 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. > > [Screenshot] KWrite being suggested instead of qvm-trust > > KWrite is suggested to edit it. > > Dolphin doesn't mark untrusted files as a specific file-type, > instead it simply says 'unknown': > > [Screenshot] 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 :)** Renaming the file might not be that good idea. What if there is already a (different) file with .untrusted suffix in the same directory? So, this may require some patching... Just make sure first there is no another plugin API in dolphin for things like this. > 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. > > [Screenshot] 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** > > 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? /usr/share should not be modified at runtime. As we're talking about configuration, it's better to put it in /etc/qubes/ (defaults for all VMs based on given template) and ~/.config/qubes/ (VM local list) - merge lists from those two places. And qvm-trust tool should modify the later. Merging two lists means you need some way to exclude directory (for example generally ~/Downloads configured as untrusted, but you want to exclude it in "untrusted" VM - to open downloaded files directly in the VM there). Clarification: currently there is no way to mark file as "trusted" if the directory is "untrusted" (assuming file marking daemon is working), right? I think this is a good thing. > # 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. > > Anyways, that's about it for this week. Til next time! - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJZS3u+AAoJENuP0xzK19cskOMH/A2tsQtHisafw6L/3dlc6vVH CSXaVz09r4kGmSF0FKwwi4IouhdezqItkHj9FzUwsA9ZBov612KEjdYDhLM4NkHf sYV5Jdhp0ZgNrWIv2SC+ypeJ01Qbl1tuoK1uDT0wBNQxc1B58BSHsuH/de61XMbN 88v1d4ZfHuc2GBf+eqRWxU299YIgCgctLDnL4VHCjvFQM5cy87KMm5gZN++gaz+V RHWgYE1q8T7aphWHu4g49qEcsTTlI0Mqzcsu+Ko8SS2oZhoj5VL6r2NaMuXVRSQQ g5P7PdMEgzzZ2bfp7+pobw5+1PLSwglYIst5zpGAUktchyIjQKEk8joBpNXQFAQ= =h5Fo -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170622081141.GL3857%40mail-itl. For more options, visit https://groups.google.com/d/optout.
