[GSoC] Qubes-MIME-Handlers Weekly Progress Report #2

[Andrew Morgan]

Hey everyone, another week another progress report.

As always, you can find the report with screenshots here:
https://blog.amorgan.xyz/gsoc-weekly-progress-report-2.html

Otherwise the text-only version is reproduced below:

---

The work this week consisted of finishing off the context menus within
Nautilus and Dolphin. I'm happy to report that they've both been
finished off and accompanied by some icons from GNOME's Adwaita icon set.

They actually work now too :)

Some screenshots below:

[] Icons appear in menu items now in Nautilus

[] We also have a checkmark icon to indicate to the user that a folder
is marked as untrusted

[] The popup menu now includes the name of the file that is being marked
as well as the file type

[] Handy icons now show up on untrusted files!

# Extended File Attribute Troubles

As discovered earlier in the week, applied Extended File Attributes can
get lost after some programs (i.e vim) edit them. This is due to the
editor's nature of updating the file by first destroying it, then
recreating it later from their temporarily modified buffer. This method
is efficient, but unfortunately any file attributes that may be attached
to the file that the editor doesn't know about will be lost after the
original file is deleted.

You may think that this is a total show-stopper for Extended File
Attributes all together, but they actually still work in our use case,
as the goal is to prevent local modification of marked files, while
sending them to a separate VM for editing.

Because of this, the only program we have to make aware of our special
Extended File Attribute is the program that handles the transfer between
the two VMs. In our case, this program is qvm-open-in-(d)vm. By simply
reading the Extended File Attributes upon sending the file, and
reapplying them once it gets the file back, we retain our mark,
regardless of what happens to the file in the destination VM.

# 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.

# 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!

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!

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Wed, Jun 14, 2017 at 03:03:00AM -0700, Andrew Morgan wrote:
> Hey everyone, another week another progress report.
>
> As always, you can find the report with screenshots here:
> https://blog.amorgan.xyz/gsoc-weekly-progress-report-2.html
>
> Otherwise the text-only version is reproduced below:
>
> ---
>
> The work this week consisted of finishing off the context menus within
> Nautilus and Dolphin. I'm happy to report that they've both been
> finished off and accompanied by some icons from GNOME's Adwaita icon set.
>
> They actually work now too :)
>
> Some screenshots below:
>
> [] Icons appear in menu items now in Nautilus
>
> [] We also have a checkmark icon to indicate to the user that a folder
> is marked as untrusted
>
> [] The popup menu now includes the name of the file that is being marked
> as well as the file type

This window could use some better title ;)

> [] Handy icons now show up on untrusted files!

(...)

> # 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.

> # 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/

> 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!

- --
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

iQEcBAEBCAAGBQJZQbRzAAoJENuP0xzK19csslAH/jKp0cyvpzSbLnxRBEEhIoFH
NAHvMlcq8rp2BCyCIUF3MLNxo5Mxz4vcN55IdO4vU83tGXRvTln2IJXLoNigVzkM
RzwYiBScG3jX6uQI5K9cYnkh0GlI0uyzLow9AhTS8FuSKUMZQukZpEB23Ra6nZtk
FiwU0mu/a9PRPIv9xn1YSMlcpFr96Jm9TysKLnqmda8/gb8oYPomhGbe6yg7/kjr
H6B+20byrycwSPEIUCmJ608cOqLzUMcXQYPI/INGoU1Ea33HFgVELuSN9lscF6eE
esFFRFTWgd8efuQX+Hhj9bp+n7C+r+FjqAJARSfIh2nHv4AFHbrX+hn9dUTUAXQ=
=xaiL
-----END PGP SIGNATURE-----

[Andrew Morgan]

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:
>> Hey everyone, another week another progress report.
>
>> As always, you can find the report with screenshots here:
>> https://blog.amorgan.xyz/gsoc-weekly-progress-report-2.html
>
>> Otherwise the text-only version is reproduced below:
>
>> ---
>
>> The work this week consisted of finishing off the context menus within
>> Nautilus and Dolphin. I'm happy to report that they've both been
>> finished off and accompanied by some icons from GNOME's Adwaita icon set.
>
>> They actually work now too :)
>
>> Some screenshots below:
>
>> [] Icons appear in menu items now in Nautilus
>
>> [] We also have a checkmark icon to indicate to the user that a folder
>> is marked as untrusted
>
>> [] The popup menu now includes the name of the file that is being marked
>> as well as the file type
>
> This window could use some better title ;)

Derp, so focused on the window content I didn't even notice I hadn't
changed that yet :P

>
>> [] Handy icons now show up on untrusted files!
>
> (...)
>
>> # 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.

>
>> # 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.
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)

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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!
> >
> >
> >
>
>

- --
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

iQEcBAEBCAAGBQJZQgHLAAoJENuP0xzK19cszh8H/3QlZJB7ck9LZY81AyJ3g2xE
YS11Nh+/S+v/4okz9b4a6xIpODRCaTvOrfPzsc1S/2rm5u1iiKTnIfiiuPRx+LkM
xJUwLg/fHsUPW+LhxgzKTpro8HxNWSZoMFts3pB3s1y/IY1AoO3Pp2BwqqpT09NH
uihZMi6MKZx4IyIscyLgBk3tZeh6YpNB1wijh47LB6pcr8mhvw4Rfrp1Yiaiqhlz
fUAzsGyG/FSJVauGBxLFnn04lQxTbIZ+80/KWHVQOK7ibXB1oH93q6E9nC7V32GG
lTrqHXdE9Z/2ja6gafERUAGp9GDbgz/a/ixhotBiOP/oE98kUbCZ7e2L8BJ/iDY=
=l5xs
-----END PGP SIGNATURE-----

[Andrew Morgan]

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

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

- --
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

iQEcBAEBCAAGBQJZSOGvAAoJENuP0xzK19csKhsH/26ZCHSKwjH8ZGogIVs1S/RL
t8QSOwZ2o6+Dq1BtY492Rqju9jZVit2XNSb4Adi9nRFetgNiMbl5opNfHX2VVPHW
t8GsnXQKyBxGfKMDL6GPaKCGsxnrmMo0eyMwJjBWeW6x8yltPPE2OkCbbPGVDOC6
WvcOExJQrl2e9L3oYUtiX5vn183wzu0EmkG6+1djN2jLDboIllmmAJNGFemByPYl
ZpJzq5s3qwtQZundDa6+2fVZcha7/hiGfH+2nZ+gmQVl4ee+IPCd42vlGBfHNbEu
c5HAMsP6eqpzHTL/yZWouYyZFNkGXt1Rpqq5F/7ur3dbiHOwDZ7D5uLqHJw6oKA=
=9V8G
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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-----