On 06/14/2017 08:41 PM, Marek Marczykowski-Górecki wrote: > On Wed, Jun 14, 2017 at 06:20:10PM -0700, Andrew Morgan wrote: >> On 06/14/2017 03:11 PM, Marek Marczykowski-Górecki wrote: >>> On Wed, Jun 14, 2017 at 03:03:00AM -0700, Andrew Morgan wrote: >>>> # Denying Local Read Permissions on Untrusted Files >>> >>>> To prevent this mark otherwise being accidentally destroyed on the >>>> originating VM, we can simply deny all users permission to read or write >>>> from it (through a chmod 0). Props to my mentor Marek for the suggestion. >>> >>>> This has the one hiccup of which we can no longer read a file's Extended >>>> File Attributes, however our code can simply 'unlock' the file before >>>> processing it by chmod'ing the file back to 0644 before processing, and >>>> 'locking' it again afterwards. >>> >>> Also worth checking how other file manager actions handle this - moving >>> file, viewing its properties, copying it... >>> And even if copying do work, check if xattrs are preserved. > >> Well as we `chmod 0` the file copying won't work as the file cannot be >> read. This may present some UX issues, and we should inform the user >> that a file must be 'unlocked' first before it can be moved. > >> From my testing xattrs are preserved in Nautilus when >> copying/moving/renaming, while Dolphin preserves it with renaming and >> moving, but not copying. > >> We /could/ provide functionality in our extensions to move/copy/rename >> the file such that it would be able to unlock and relock the file. I >> could add this to the list of stretch goals perhaps. > > Lets keep it very low on the priority list. > >>>> # Conclusion >>> >>>> Now that the GUI is all finished, it's time to work on making the File >>>> Managers (Nautilus and Dolphin) aware of untrusted files. While it's >>>> easy enough to check for untrusted files on a right-click basis, we also >>>> need to check their status on a single or double left-click (i.e when a >>>> file is opened). >>> >>>> Originally I planned to patch the File Managers to allow for running >>>> code on a left-click, however after creating the Nautilus extension, it >>>> seems to already do this by default. Coupled with the fact that files >>>> are no longer locally editable and thus cannot be opened automatically, >>>> we may not actually need to patch Nautilus at all! >>> >>> \o/ > >> So turns out while we do get a ping in our extension when a user tries >> to open a file, we still need to prevent the file from attempting to be >> opened - otherwise a rather annoying message will pop up complaining it >> can't be read. > >> Additionally, I'm not entirely sure if the ping we receive is >> indistinguishable from the one we get when a user right-clicks a file. > >> So patching will still be necessary to: > >> 1. Prevent opening of the file all-together. > > Not really preventing - just changing the action (application to open > the file). > >> 2. Send a separate message to the extension that a user is opening a >> file, versus just clicking on it. (there may be a workaround for this >> one, still looking) > >>> >>>> Dolphin may still require a patch, but I'll be looking for ways to >>>> possibly get away with not needing to while working on the Nautilus >>>> version first. >>> >>>> Any and all feedback is appreciated, see you all in a week! >>> >>> >>>
So based on the suggestion of using a generic file handler for files once more (which now works because chmod 0'ing each file gives them the same mimetype), I've managed to get setting files as untrusted/trusted working pretty flawlessly along with an accompanying dummy .desktop file associated with the mimetype which successfully opens them in a disposableVM! I'll post about all that in the weekly progress report, however while working on this and having a family member try out the setup for QA purposes, it became increasingly obvious that by introducing the ability to mark file-types are untrusted, we're both complicating the implementation as well as the UX, while adding a feature that may not actually be that useful. After once again going through the issue where the initial idea was first born ( https://github.com/QubesOS/qubes-issues/issues/441 ), it seems that the desired use case is marking individual files (such as Evil.pdf) as well as folders (Downloads/, QubesIncoming/) as untrusted. That discussion, and now I, feel as if there really isn't a need to mark an entire filetype as untrusted, since they're not really specific to any one threat (not all PDFs are evil). Thinking about what it would look like if this were eliminated, we could ditch the Zenity UI altogether and simply have a check mark menu item to mark files untrusted, similar to what's already implemented for folders, which would simply some of the clutter to a nice degree. Let me what you think. Thanks, Andrew Morgan -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/oi9vee%24pp9%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
