-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Qubes MIME handlers #441
Comments
Comment by marmarek on 6 Feb 2012 13:14 UTC |
Comment by joanna on 6 Feb 2012 13:20 UTC |
Modified by joanna on 9 Apr 2012 09:45 UTC |
Modified by joanna on 8 Oct 2012 09:28 UTC |
Comment by joanna on 24 Feb 2013 15:31 UTC http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html |
Modified by joanna on 1 Aug 2013 11:32 UTC |
Modified by joanna on 5 Dec 2013 18:58 UTC |
Modified by joanna on 20 Apr 2014 17:03 UTC |
Modified by joanna on 20 Apr 2014 17:05 UTC |
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 |
Yes, good idea. |
I'm not sure how to correctly pull request this feature, but I believe I have a working solution here: |
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). |
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:
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)? |
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. |
Perhaps we can have the first version with hardcoded "-i untrusted" and "~/Downloads"? |
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/ 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: |
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:// ? |
This shouldn't be a problem (if Chrome respects XDG): simply add
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). |
Community Dev: none (help wanted)
Partial PoC: https://github.com/kulinacs/qubes-desktop
Post: http://theinvisiblethings.blogspot.com/2013/02/converting-untrusted-pdfs-into-trusted.html
Discussion: https://groups.google.com/d/msgid/qubes-users/dc777e37-a4a2-4ea8-bb80-4b5fb5aceeac%40googlegroups.com
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
The text was updated successfully, but these errors were encountered: