Qubes MIME handlers

[marmarek]

Reported by joanna on 6 Feb 2012 11:25 UTC
E.g. if a user manually opens a file in DispVM once, then this file will always by opened in DispVM by default.

If this is simple, it would be a great feature. If not simple, we should postpone it until after 1.0 -- TBD.

Migrated-From: https://wiki.qubes-os.org/ticket/441

[marmarek]

Comment by marmarek on 6 Feb 2012 13:14 UTC
Define "open". Double-click in nautilus?

[marmarek]

Comment by marmarek on 6 Feb 2012 13:14 UTC
Define "open". Double-click in nautilus?

[marmarek]

Comment by joanna on 6 Feb 2012 13:20 UTC
Yup.

[marmarek]

Comment by joanna on 6 Feb 2012 13:20 UTC
Yup.

[marmarek]

Modified by joanna on 9 Apr 2012 09:45 UTC

[marmarek]

Modified by joanna on 9 Apr 2012 09:45 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:28 UTC

[marmarek]

Modified by joanna on 8 Oct 2012 09:28 UTC

[marmarek]

Comment by joanna on 24 Feb 2013 15:31 UTC
This has been further discussed at the end of this post:

http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

[marmarek]

Comment by joanna on 24 Feb 2013 15:31 UTC
This has been further discussed at the end of this post:

http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html

[marmarek]

Modified by joanna on 1 Aug 2013 11:32 UTC

[marmarek]

Modified by joanna on 1 Aug 2013 11:32 UTC

[marmarek]

Modified by joanna on 5 Dec 2013 18:58 UTC

[marmarek]

Modified by joanna on 5 Dec 2013 18:58 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:03 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:03 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:05 UTC

[marmarek]

Modified by joanna on 20 Apr 2014 17:05 UTC

[marmarek]

Related: https://groups.google.com/d/msgid/qubes-users/dc777e37-a4a2-4ea8-bb80-4b5fb5aceeac%40googlegroups.com

[marmarek]

Related: https://groups.google.com/d/msgid/qubes-users/dc777e37-a4a2-4ea8-bb80-4b5fb5aceeac%40googlegroups.com

[andrewdavidwong]

Just checking in, since the last development update on this appears to have been over a year go. Is @rootkovska actively working on this? If not, may I remove the assignment and add the help wanted label?

[andrewdavidwong]

Just checking in, since the last development update on this appears to have been over a year go. Is @rootkovska actively working on this? If not, may I remove the assignment and add the help wanted label?

[marmarek]

Yes, good idea.

[marmarek]

Yes, good idea.

[kulinacs]

I'm not sure how to correctly pull request this feature, but I believe I have a working solution here:
https://github.com/kulinacs/qubes-desktop
By adding the qvm-open-in-dvm.desktop file to your applications folder, it allows file managers to recognize qvm-open-in-dvm as an executable to open file types. The user can then use their respective file manager to set it as the default application.

[kulinacs]

I'm not sure how to correctly pull request this feature, but I believe I have a working solution here:
https://github.com/kulinacs/qubes-desktop
By adding the qvm-open-in-dvm.desktop file to your applications folder, it allows file managers to recognize qvm-open-in-dvm as an executable to open file types. The user can then use their respective file manager to set it as the default application.

[marmarek]

Thanks, this is one part of this ticket. It can be included in https://github.com/qubesos/qubes-core-agent-linux repo and IMO can be so now (regardless of the other part).
The other part is a mechanism to remember user choice on file basis - for example to mark some files to always open in DispVM, while other files (possibly with the same type) - not.

[marmarek]

Thanks, this is one part of this ticket. It can be included in https://github.com/qubesos/qubes-core-agent-linux repo and IMO can be so now (regardless of the other part).
The other part is a mechanism to remember user choice on file basis - for example to mark some files to always open in DispVM, while other files (possibly with the same type) - not.

[rootkovska]

Since it's tricky to properly implement persistent-yet-not-spoofable flags on files for determining on whether a given file should be opened in DispVM or not, etc, I propose a simplified solution:

Have qubes-registered .desktop files that determines whether to open in a DispVM based on the following heuristics:

1. If path starts with: ~/QubesIncoming/ or ~/Downloads/
2. If the path contains the following string untrusted (case insensitive)

This should cover most of the cases, such as default treating any files downloaded from the Internet as untrusted by default, unless the user decided to move it somewhere else explicitly (and both the user's Web browser as well as the email client could be configured to save there by default).

The match for "untrusted" string in the middle of a path is meant for users who would like to explicitly insert some untrusted files into otherwise trusted directory trees (e.g. some 3rd party PDF inserted into their trusted work project tree). Also will cover ~/UntrustedPDFs case.

Of course these rules could be configurable, e.g. an env variable overridable in ~/.bashrc or /rw/config. E.g.: `QUBES_UNTRUSTED_PATH="^/home/users/Mydownloads". Note we should enforce patching always done on the canonical paths.

The above can easily be done for specif files, e.g. PDFs, JPEGs, etc, by substituting the corresponding .desktop files. Can we provide a generic .desktop files that will always be consulted first before resorting to the specific files provided by various apps (evince, etc)?

[rootkovska]

Since it's tricky to properly implement persistent-yet-not-spoofable flags on files for determining on whether a given file should be opened in DispVM or not, etc, I propose a simplified solution:

Have qubes-registered .desktop files that determines whether to open in a DispVM based on the following heuristics:

1. If path starts with: ~/QubesIncoming/ or ~/Downloads/
2. If the path contains the following string untrusted (case insensitive)

This should cover most of the cases, such as default treating any files downloaded from the Internet as untrusted by default, unless the user decided to move it somewhere else explicitly (and both the user's Web browser as well as the email client could be configured to save there by default).

The match for "untrusted" string in the middle of a path is meant for users who would like to explicitly insert some untrusted files into otherwise trusted directory trees (e.g. some 3rd party PDF inserted into their trusted work project tree). Also will cover ~/UntrustedPDFs case.

Of course these rules could be configurable, e.g. an env variable overridable in ~/.bashrc or /rw/config. E.g.: `QUBES_UNTRUSTED_PATH="^/home/users/Mydownloads". Note we should enforce patching always done on the canonical paths.

The above can easily be done for specif files, e.g. PDFs, JPEGs, etc, by substituting the corresponding .desktop files. Can we provide a generic .desktop files that will always be consulted first before resorting to the specific files provided by various apps (evince, etc)?

[v6ak]

Joanna, it looks mostly like a reasonable hack. The only part I am not sure about is QUBES_UNTRUSTED_PATH environment variable. Something suggests me this will be error prone, maybe someone will set it in .bashrc and it will work in some cases (when running from Bash), but not in some others (when running from qvm-run). On one hand, such power users might be aware of such behavior, on the other hand, I am not sure if this will be always the case.

[v6ak]

Joanna, it looks mostly like a reasonable hack. The only part I am not sure about is QUBES_UNTRUSTED_PATH environment variable. Something suggests me this will be error prone, maybe someone will set it in .bashrc and it will work in some cases (when running from Bash), but not in some others (when running from qvm-run). On one hand, such power users might be aware of such behavior, on the other hand, I am not sure if this will be always the case.

[rootkovska]

Perhaps we can have the first version with hardcoded "-i untrusted" and "~/Downloads"?

[rootkovska]

Perhaps we can have the first version with hardcoded "-i untrusted" and "~/Downloads"?

[rootkovska]

Here are some ready-to-use .desktop files for both URL and MIME handling:

https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/
https://github.com/kulinacs/qubes-desktop

It seems like all we need is to write a simple wrapper program (which would be Exec'ed by such a .desktop file) that: 1) checks if the path ($1) matches ^~/Downloads or contains "untrusted" (case insensitive), and then, if yes, run: qvm-open-in-(d)vm $1.

[rootkovska]

Here are some ready-to-use .desktop files for both URL and MIME handling:

https://micahflee.com/2016/06/qubes-tip-opening-links-in-your-preferred-appvm/
https://github.com/kulinacs/qubes-desktop

It seems like all we need is to write a simple wrapper program (which would be Exec'ed by such a .desktop file) that: 1) checks if the path ($1) matches ^~/Downloads or contains "untrusted" (case insensitive), and then, if yes, run: qvm-open-in-(d)vm $1.

[rootkovska]

Also, while at at, it might be sometimes very useful to be able to set custom URI handlers for Chrome. E.g. I might want all http:// links from by work-browser VM to open automatically in work-untrusted VM. It seems like we could use e.g. this Chrome extension for this:

http://bendavis78.github.io/chrome-extension-redirector/

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

[rootkovska]

Also, while at at, it might be sometimes very useful to be able to set custom URI handlers for Chrome. E.g. I might want all http:// links from by work-browser VM to open automatically in work-untrusted VM. It seems like we could use e.g. this Chrome extension for this:

http://bendavis78.github.io/chrome-extension-redirector/

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

[marmarek]

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

This shouldn't be a problem (if Chrome respects XDG): simply add MimeType=x-scheme-type/qubes-dvm to .desktop file, like this:

[user@testvm applications]$ pwd
/usr/share/applications
[user@testvm applications]$ cat qubes-open-dvm.desktop
[Desktop Entry]
Version=1.0
Type=Application
Exec=/bin/sh -c 'qvm-open-in-dvm $(echo %u | sed -e s:^qubes-dvm:http:)'
MimeType=x-scheme-handler/qubes-dvm
[user@testvm applications]$ sudo update-desktop-database
[user@testvm applications]$ xdg-open qubes-dvm://qubes-os.org/

And the same for https. It looks to also work in Chrome, but you get "External Protocol Request" confirmation (at least for the first time).

[marmarek]

... but we also need a way to register Qubes qvm-open-in-(d)vm as Chrome URL handlers, e.g.: qubes-vm:// and qubes-dvm:// ?

This shouldn't be a problem (if Chrome respects XDG): simply add MimeType=x-scheme-type/qubes-dvm to .desktop file, like this:

[user@testvm applications]$ pwd
/usr/share/applications
[user@testvm applications]$ cat qubes-open-dvm.desktop
[Desktop Entry]
Version=1.0
Type=Application
Exec=/bin/sh -c 'qvm-open-in-dvm $(echo %u | sed -e s:^qubes-dvm:http:)'
MimeType=x-scheme-handler/qubes-dvm
[user@testvm applications]$ sudo update-desktop-database
[user@testvm applications]$ xdg-open qubes-dvm://qubes-os.org/

And the same for https. It looks to also work in Chrome, but you get "External Protocol Request" confirmation (at least for the first time).