-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Jun 20, 2017 at 10:49:50AM +0200, Marek Marczykowski-Górecki wrote: > On Mon, Jun 19, 2017 at 06:57:37PM -0700, Andrew Morgan wrote: > > 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! > > Yay! > > > 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). > > You're right, not all PDFs are evil. But at the same time, PDF format is > much more complex (and applications to handle it too) than, say, .txt. > On the other hand, this all applies to files coming from some external > source - like the internet, or some other VM. > There are multiple other methods already to set qvm-open-in-dvm as > default PDF viewer for example. > > > 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. > > All in all, I agree - having this simplified to marking > files/directories is a good idea.
One thing, that may be useful to have based on file type - different DispVMs. For example to open .docx in Windows (or ReactOS) based DispVM. This is hardly possible in QUbes 3.2, but is much easier in Qubes 4.0. But this is somehow independent of marking files trusted/untrusted - this still makes sense on file/directory basis. - -- 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 iQEcBAEBCAAGBQJZSOL7AAoJENuP0xzK19csY58H/16MqTRvhlw+jeQg7E6ZaaDV SDbLojce3Bleh4iU82Jtdr4INeeV1NmCyV3GdCALUH2u4yRXGEQMb34CzkeZDYoI z7fuWaI4Aj1XLTCOlywBOiRGY2ebfLboPJFaMyIs8OYLxXGx29ZMsOjzkzgEV3nK RwC3s1T99taX6RqxyPi1Sa49ZVYNIqPzI3pTi+/ly2hVH8t5noB8gA8HXKBv61C5 dxy1sVNdO/jEC8pciqrk51YP15FZoEqd2LfmxY4S1bmD2PsKWIpO+0jwHpq6oHE9 JG1sWGTg86VR08WaJ5J/5Q62INqi7fBIgU6htMQ3ynBtMg0492GMciUeuhuRX6A= =Ae4N -----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 [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/20170620085522.GJ1268%40mail-itl. For more options, visit https://groups.google.com/d/optout.
