On 03/15/2017 05:20 PM, Jean-Philippe Ouellet wrote: > On Wed, Mar 15, 2017 at 6:07 PM, Andrew Morgan > <[email protected]> wrote: >> I was thinking about the UX and UI of how a user would mark a file as >> untrusted/always open in a DispVM. In the original issue there were some >> debates on how a user would know/could mark a file as untrusted and I've >> come up with the following potential solution: > > You may wish to re-read the link in my earlier mail: > > On Fri, Mar 10, 2017 at 3:22 PM, Jean-Philippe Ouellet > <[email protected]> wrote: >> There are standardized extended filesystem attributes [1] which are >> widely adopted now, and should be a good starting point for >> implementing this. >> >> [1]: https://www.freedesktop.org/wiki/CommonExtendedAttributes/ >> >> >> Example: >> $ getfattr -d genode-foundations-16-05.pdf >> # file: genode-foundations-16-05.pdf >> user.xdg.origin.url="https://genode.org/documentation/genode-foundations-16-05.pdf"; > > These attributes are set automatically by many programs which produce > files from untrusted sources (browsers, email clients, etc.), meaning > you likely do not need to worry about a way to set them manually, but > rather a way to determine how to handle them when they are found. > > Other systems (non-linux) do this too (IIRC OS X sets > com.apple.quarantine or something), and presumably windows has its > equivalent too (although after actively avoiding using windows for > nearly the past decade, I find that I know little about it ;) > > The task then would be to extend qfilecopy [1] to transfer these > attributes, and possibly translate them into the equivelant windows > versions if you wish to support windows. WIndows support would > certainly be great, but I'd aim for getting it working on linux first. > > [1]: https://www.qubes-os.org/doc/qfilecopy/ >
Hey Jean-Philippe, Thanks for the insight on how existing programs already utilize the EFA. I did not know some set them as untrusted. > Linux uses "security", "system", "trusted", and "user". I assume you're referring to this line on the freedesktop spec? On my own system however, I don't seem to find the same mark of trust when downloading a file: * Download repo file .zip from GitHub * [user@untrusted ~]$ getfattr -d ~/Downloads/a53420.zip [user@untrusted ~]$ Firefox hasn't added anything in terms of extended attributes to the file, and I haven't changed any settings related to this as far as I know. Perhaps I'm doing something wrong here? > you likely do not need to worry about a way to set them manually, but > rather a way to determine how to handle them when they are found. This would be nice but rather tricky to implement I feel, as we would have to keep a record of which program namespaces and which values would represent a low level of trust and act upon that. This is of course assuming I am only able to read these attributes based on their textual values, but so far I do not know any other way. When a program fails to mark that trust correctly or at all, it is potentially putting the user in danger or at the least inconveniencing/confusing them. I still believe that only setting a file to open in a certain domain based on the user's own actions, such as setting an option for that specific file, is clearest for the user in what is going to happen when they open a particular file. > The task then would be to extend qfilecopy [1] to transfer these attributes In the issue on the GSoC page it states: > Allow setting persistent flag for a file that should be opened in specific > way (“locally”); this flag should local to the VM - it shouldn’t be possible > to preserve (or even fabricate) the flag while transferring the file from/to > VM. I assuming by this bullet point we don't want the attribute transferred? >From my own testing the flags are already stripped when using qfilecopy, thus we shouldn't have to do any work here, unless I'm misunderstanding you? :) Thanks for being patient and answering my questions! 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/oacng5%24hfe%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
