On Wed, Mar 15, 2017 at 8:49 PM, Andrew Morgan <[email protected]> wrote: > On 03/15/2017 05:20 PM, Jean-Philippe Ouellet wrote: > 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?
Ah, indeed. I can reproduce your observed behavior. I use chrome nearly exclusively and hadn't noticed. >> 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. Upon reviewing the arguments in [1] again, and checking more programs to see if they set the xdg flags, I now agree with you. [1]: https://github.com/QubesOS/qubes-issues/issues/441#issuecomment-253731556 >> 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? :) I have not thought this through, and defer to those who have. -- 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/CABQWM_Dk%2BLRpgbdO2Mg1CvOdSq%3DYr75VwMzp8Fc-AM%2BWM7VXHQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
