GSoC Student Introduction

[anoa]

Hello all,

My name is Andrew Morgan, and I'm a sophomore studying computer science
and engineering at the University of California Merced. I have been
running QubesOS on my laptop since November 2016 and have been
enthralled with the ability to control everything about my computing
experience.

That being said, its not without its flaws, and I'd like to dedicate a
portion of my summer to help out.

In terms of issues I'd like to tackle, I think I can make ample progress
in implementing either Qubes-aware MIME handlers, a LoggingVM or a
custom connection wizard for Tor. I only intend to pick one of these
issues (for the time being), and I'd like to use this month to figure
out which one would be the most feasible given my current experience.

I've posted a few times on the qubes-users mailing list under the
monikers 'anoa' and 'Andrew M', but regularly browser both qubes-users
and qubes-dev.

I have decent experience working with open-source projects. You can find
me on GitHub here:

https://github.com/anoadragon453

or on my website:

https://amorgan.xyz

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Welcome, Andrew! We're very happy that you're interested in Qubes and
would welcome your help on any of the ideas you mentioned. Once you've
decided on one, I recommend reaching out to the mentor for that idea
and beginning to write a draft proposal. If you need help deciding,
I'm sure anyone around here would be happy to help.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJYwYtOAAoJENtN07w5UDAwRwYQAKXrMX2mZMpjygLQmANc0WRm
60RYjKNyvI01EsvBtr3Twxm671wpcUl2LJUME/fmLpbN7uEGlMWB0ndgpWgSSicU
oQn2f6z/UCYPBS4mwcgJ+7NC8wckiSwCfst8TwRMz/Q6x5+hyIS+oKWpQlJNBDl/
Hh7O8TO9QSweu7DrjgmIMWNNNqq3fWAIcJBCK8tLV/p4QbTIT5H2MdRSdRcX4ieM
gK8jPjfCSMRkF4Usd1N70/jbFjvB7dlqr4ZpXIM8ghf2vbll5MvWcL5JhPIew63v
SCh1Gvvh/CGbsxGd1GoVZMdhmf7saDNuQF1of1XPvR2d0AOG3S4W4CS7+utE1uzc
2Inle7fx/hcCoHxCN0c5WBx9v8O1ozXg/3aXrd5Fdz36lflu7HmjGt/qfJTe+fb6
Ft/DmMIgcA0eW39Z/SovnMeFeVXXbqM01sHxWz3PIrhnPtwJTbFcqlCc825YFQO9
eZM+QHXY8F7dxRBuBG3kPfHKB9rCDZUGpcnQIisUYRGAAJVzS6r4cTTw3dl7Mtmz
gsNx8++79Zl7wi+0zb9WhMeYIbgjVx8HDhkSxqCwPc4g3sFG0Arr1lkTlp3lRt+1
Mr2zdUg0UK5NbKaUfnnhnWddjq5waYMfjgOJUOYvmpM8ef1q0zmjfe24VHbgXuUh
5x0MxjSNNQSWTqCYEh2p
=nYiU
-----END PGP SIGNATURE-----

[anoa]

Thank you for the introduction!

After a bit of research it seems the most feasible challenge for me
would be Qubes-aware MIME-type handling on our supported file managers.
For this task Marek Marczykowski-Górecki is the mentor, and I realize he
browses these mailing lists.

Marek, would the best form of contact and project discussion be through
these lists, irc or 1-to-1 email? I understand that keeping our
communications about the project public would likely be best.

In terms of concept, I have already started thinking about how to
implement this, however I would like to clarify one thing first before
presenting a design as the issue description doesn't really make this
too clear.

Are we implementing MIME-handling to open a specific file/type in
DisposableVMs only, or should the user be able to choose/enter any one
of their installed VMs? As a Qubes user I would like the ability to open
all PDFs in, say, my work AppVM, rather than only being able to only set
global rules for files to open in Disposable VMs.

I also don't believe implementing the ability for the user to choose a
arbitrary destination VM would be much harder than only letting them use
a Disposable VM, but I want to make sure I understand what is expected
before going any further.

Thanks!
Andrew Morgan

[Marek Marczykowski-Górecki]

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

Yes, this mailing list is probably the best.

> In terms of concept, I have already started thinking about how to
> implement this, however I would like to clarify one thing first before
> presenting a design as the issue description doesn't really make this
> too clear.
>
> Are we implementing MIME-handling to open a specific file/type in
> DisposableVMs only, or should the user be able to choose/enter any one
> of their installed VMs? As a Qubes user I would like the ability to open
> all PDFs in, say, my work AppVM, rather than only being able to only set
> global rules for files to open in Disposable VMs.

Technically it's indeed very similar, but in practice it doesn't make
much sense - if you want to open some file always in the same
non-disposable VM, simply keep the file there.

IMO much more important (and not so easy) part is to keep information
which files should be opened where. For example flag files downloaded
from the internet to open in Disposable VMs (even when moved out of
"Downloads" directory), but files converted using qvm-convert-pdf open
locally.

> I also don't believe implementing the ability for the user to choose a
> arbitrary destination VM would be much harder than only letting them use
> a Disposable VM, but I want to make sure I understand what is expected
> before going any further.
>
> Thanks!
> Andrew Morgan
>

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

iQEcBAEBCAAGBQJYwukVAAoJENuP0xzK19csgyIH+gIMK5y/Kek0Y0cQkyPV+lD6
XxNccn7QTeGSZD68fIvCSQAQhviPibyrKilJ10s8fZvK2J+NBi8zjeHLkRLZvkIn
zOnKdFyAWcDYk8KX7vhHe8mARR3AtXlkqppVe1u2j7VWSEtBvPPwY5iDjMnJ/n2l
a3UJDaus46vwF5iJc26USI/WcbCTqXKffVaoKG9xGrWLFtrVWCQwxt5OavDX7yd0
MuqHdZF7L5ER0cgq9bU5whld9p3osseUfMeUQYnjPjvCKlt9/xgM5fqtdAJkeG9D
CRkgPwk+OkFStie1zbhfOeq6O7aUdNSePVwxuANl/15sJTh2VqK46XMdTJ1nwK4=
=GF1/
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

On Fri, Mar 10, 2017 at 12:57 PM, Marek Marczykowski-Górecki
<marm...@invisiblethingslab.com> wrote:
> On Thu, Mar 09, 2017 at 06:43:04PM -0800, anoa wrote:
>> In terms of concept, I have already started thinking about how to
>> implement this, however I would like to clarify one thing first before
>> presenting a design as the issue description doesn't really make this
>> too clear.
>>
>> Are we implementing MIME-handling to open a specific file/type in
>> DisposableVMs only, or should the user be able to choose/enter any one
>> of their installed VMs? As a Qubes user I would like the ability to open
>> all PDFs in, say, my work AppVM, rather than only being able to only set
>> global rules for files to open in Disposable VMs.
>
> Technically it's indeed very similar, but in practice it doesn't make
> much sense - if you want to open some file always in the same
> non-disposable VM, simply keep the file there.
>
> IMO much more important (and not so easy) part is to keep information
> which files should be opened where. For example flag files downloaded
> from the internet to open in Disposable VMs (even when moved out of
> "Downloads" directory), but files converted using qvm-convert-pdf open
> locally.

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"

[Marek Marczykowski-Górecki]

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

On Sat, Mar 11, 2017 at 01:07:30AM +0000, Andrew Clausen wrote:
> Hi Marek,
>
> On 10 March 2017 at 17:57, Marek Marczykowski-Górecki <

> marm...@invisiblethingslab.com> wrote:
>
> > > Are we implementing MIME-handling to open a specific file/type in
> > > DisposableVMs only, or should the user be able to choose/enter any one
> > > of their installed VMs? As a Qubes user I would like the ability to open
> > > all PDFs in, say, my work AppVM, rather than only being able to only set
> > > global rules for files to open in Disposable VMs.
> >
> > Technically it's indeed very similar, but in practice it doesn't make
> > much sense - if you want to open some file always in the same
> > non-disposable VM, simply keep the file there.
> >
>

> Isn't this similar in practice too? For example, when I download a
> document in a web browser (not in Qubes), it opens is straight away in a
> document viewer; I can then click to "save a copy" from the document
> viewer. I think it makes sense to extend this standard workflow to opening
> the document in a preferred VM, where it can then be saved.
>
> For example, if I receive a PDF attachment in my "personal" VM, I usually
> want to open (and possibly save it) in my "work" VM.

There is one important difference between sending a file to a VM
(qvm-copy-to-vm) and opening it there - the later may easily compromise
target VM, especially in case of complex file formats. While
compromising Disposable VM by opening malicious file there isn't a
problem (this is exactly what Disposable VM is for), it is a problem in
case of non-Disposable VM. This means that opening a file in
non-Disposable VM should be decision made in target VM (where you sent
file), not the one sending a file there.

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

iQEcBAEBCAAGBQJYw6x+AAoJENuP0xzK19csQ6kH/1cZCU1pAGvQrEBsvLGMdQ0H
/8L/RlUx4/HuRskGyKmZ3ItBWkcVVy//rrKUFEB3RT/zyQ5JedpYyJbjyU+03Rmd
rtyZNdayi9n/mf0maSRCx29elUI+ERflGahuiIADiM55eCzrJUmx9FpCkXrjQMHw
1jl+BV321YCzYV9+tfVewBwtOLIM3E6Q02/V+3oOU25bkHT8nwziQFdOT0Rnn0t7
mr5EV+Wc2ldr6CT2iUHqCYqymDnabf1e12+6DTX8+wUJHGB1C/QgIukdTZKk5q0+
9Bsi7092ZAXXt4hOXTTPguXYobROgJQ5rUhxPN7jURvn6SB97KruAKlx+BNZd8I=
=KK9F
-----END PGP SIGNATURE-----

[Andrew Morgan]

Hey Marek,

I agree that opening a file in a non-disposable AppVM does pose a risk
to the user, however this system should still be accompanied by the
dialog box in Dom0 asking the user's permission before the file is
transferred at all, correct? We can leave out the dialog for
DisposableVMs, as currently is done now, as their compromise is not too
concerning.

As for some use cases for vm-to-vm opening, I myself have a Nextcloud
Server instance that hosts my personal, school and work files. Currently
I have an instance of Nextcloud running in each of my relevant AppVMs,
and only sync the contents necessary for that specific domain. However
this does not prevent, say my school domain from reading my work files
if it was compromised, as it is only set as a soft rule in each
Nextcloud client instance. Not to mention the system resources required
for ~4 Nextcloud instances vs. 1.

One cool use case would thus be having a "Nextcloud" AppVM, that has
been firewalled to only access the server address, where I could open
files belonging to either school, work or personal only in their
respective domains. This use case could also be solved by some sort of
"Shared Folder" between VMs, but in this case each AppVM only has access
to the necessary files at any given time, and a full-VM compromise would
not be as damaging.

Either way, I understand that this issue only currently asks for
DisposableVM opening from AppVMs, so if we want to keep it that way I'm
not objected to it. I would however not mind either way :)

Thanks,
Andrew Morgan

[Andrew Morgan]

Hey Jean-Philippe,

This is very useful, thank you.

The `attr` package is not installed in Whonix, Ubuntu or Debian by
default, so we will have to include this in our templates for this to
function seamlessly. Furthermore, while Nautilus preserves x-attributes
on copy/move/cut, Dolphin only supports it on move/cut, not copy. Some
discussion may be necessary on whether it /should/ be preserved on copy,
as you are essentially making a new file, even if the contents are
initially the same. I believe that whichever is decided on, however, it
should be consistent across all supported file managers, which may
require a patch on one of them.

It seems that what causes the above is that adding the -a flag to cp
allows cp to respect x-attr's and will copy them accordingly. It seems
that Konsole does not do this, while Nautilus does.

Windows also apparently supports Extended File Attributes on FAT, HPFS
and NTFS[0], so this should also work as a solution on Windows-based
systems as well!

[0] https://en.wikipedia.org/wiki/Extended_file_attributes#Windows_NT

Thanks,
Andrew Morgan

[Jean-Philippe Ouellet]

On Sat, Mar 11, 2017 at 3:42 AM, Andrew Morgan <an...@openmailbox.org> wrote:
> The `attr` package is not installed in Whonix, Ubuntu or Debian by
> default, so we will have to include this in our templates for this to
> function seamlessly.

Not necessarily. You could simply use a lower-level interface
[1][2][3][4] to the same thing that command accesses. Doing so would
likely be preferable anyway, as there is a preference in the Qubes
codebase for implementing things in python instead of shell scripts
for portability reasons [5].

[1]: https://pypi.python.org/pypi/xattr
[2]: http://man7.org/linux/man-pages/man5/attr.5.html
[3]: http://man7.org/linux/man-pages/man2/getxattr.2.html
[4]: http://man7.org/linux/man-pages/man2/listxattr.2.html
[5]: https://www.qubes-os.org/doc/coding-style/#bash-specific-guidelines

[Andrew Morgan]

On 03/11/2017 11:50 AM, Jean-Philippe Ouellet wrote:

Thanks Jean-Philippe,

That's great that Python has a native interface for this.

I noticed the xattr package does not have support for setting extended
file attributes (EFA) on Windows. There is one library [0] that claims
to support altering EFAs on Windows although I have not tested it yet
and it hasn't seem a commit in quite some time. I'm also unsure whether
it allows for custom attributes, which would be especially problematic
as I was planning on adding a "user.qubes.untrusted" attribute key.

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:

Be able to mark a file, folder or complete MIME-type as "untrusted".

I know the issue is mainly geared towards MIME-types, however Joanna's
comment [1] on potentially having files created in the user's
~/Downloads or ~/QubesIncoming folders always being untrusted gave me an
idea. Using the pyinotify module [2], we can easily and efficiently run
a python daemon that monitors untrusted folders and marks their contents
as untrusted as well, even when new content is created inside them. We
could also mark these files/folders with an emblem that would show up in
the file manager, clearly alerting users to what will happen when they
double-click a file.

In addition to the folders concept, I drafted a potential file dialog in
GIMP for what the user could see when right clicking > choosing to open
a file in a disposable VM:

https://imgur.com/a/cEoDx

The concept was geared to be compatible with any destination VM but we
could remove the text view and have it only for DispVM usage (though it
may come in handy for Qubes 4.x when we have multiple types of DispVMs).

For the folder marking, we could add an entry in the folder's
right-click menu with a checkbox for whether or not it and its contents
are untrusted.

Overall, the main hurdles with this project seem to be in the UX/UI
design, as well as potential Windows compatibility (I'm not sure
including an entry in the Windows right-click dialog will be as simple
as a python script).

Let me know what you think, I'm eager for feedback.

[0]: https://github.com/amdf/xattrlib
[1]:
https://github.com/QubesOS/qubes-issues/issues/441#issuecomment-253731556
[2]: https://github.com/seb-m/pyinotify


Thanks,
Andrew Morgan

[Jean-Philippe Ouellet]

On Wed, Mar 15, 2017 at 6:07 PM, Andrew Morgan <an...@openmailbox.org> 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 <j...@vt.edu> 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/

[Andrew Morgan]

On 03/15/2017 05:20 PM, Jean-Philippe Ouellet wrote:

> On Wed, Mar 15, 2017 at 6:07 PM, Andrew Morgan <anoa-1Ww2luig...@public.gmane.org> 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 <jpo-PjA...@public.gmane.org> 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

[Jean-Philippe Ouellet]

On Wed, Mar 15, 2017 at 8:49 PM, Andrew Morgan <an...@openmailbox.org> 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.

[Jean-Philippe Ouellet]

It seems this "widely adopted standard" of setting attributes is not
quite as widely adopted as I'd thought^Wimagined ;)

[Marek Marczykowski-Górecki]

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

Definitely we don't want a VM to make a file in other VM already marked
as "trustworthy, open locally" (or avoiding marking as
"untrusted, open in Disposable VM", if that would be the default action).

In some cases one VM may "trust" some other VM, but I don't think it
justifies allowing transfer of such attributes. If anything, better add
a configuration to exclude certain QubesIncoming/some-vm from automatic
marking as untrusted. But not if it's a good idea either.

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

iQEcBAEBCAAGBQJYyez/AAoJENuP0xzK19cs6doH/jBYzXqOvnMsCYzAA1me9vwe
C+rssU2K0IJE+crHEtlXTgYlVoMBpe8sqsJE/Bx2M3hjNme5Y7JZgEXTB3LqNIk0
pjKkmcOT8I/W5Hp7muTxTqjljV26Jxr4IN+Vh5kweNZagJ0V+d4WizQ//fDLyrvd
HHQkfuyio3bLzpgLPpbAY04XSLKcLZI9ofiQqHgXxISxXcNtE5jE6PV4PNUr1tiQ
veMMhxO+kWqzeED3QV4I2aJjoDekIKKN6N52Caqjtup7j9elqoyDkgDjy1d0jCBT
jWk5ZW/erGEU6/Nm0wgOd/u1i1lpjRur54xUdUEOMVwE8adEo1De0o55t99+1RE=
=kKWs
-----END PGP SIGNATURE-----

[Andrew Morgan]

On 03/15/2017 06:40 PM, Marek Marczykowski-Górecki wrote:
> On Wed, Mar 15, 2017 at 09:13:22PM -0400, Jean-Philippe Ouellet wrote:

>> On Wed, Mar 15, 2017 at 8:49 PM, Andrew Morgan <anoa-1Ww2luig...@public.gmane.org> wrote:
>>> On 03/15/2017 05:20 PM, Jean-Philippe Ouellet wrote:
>>>> 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.
>
> Definitely we don't want a VM to make a file in other VM already marked
> as "trustworthy, open locally" (or avoiding marking as
> "untrusted, open in Disposable VM", if that would be the default action).
>
> In some cases one VM may "trust" some other VM, but I don't think it
> justifies allowing transfer of such attributes. If anything, better add
> a configuration to exclude certain QubesIncoming/some-vm from automatic
> marking as untrusted. But not if it's a good idea either.
>
>

>> In some cases one VM may "trust" some other VM, but I don't think it
>> justifies allowing transfer of such attributes. If anything, better add
>> a configuration to exclude certain QubesIncoming/some-vm from automatic
>> marking as untrusted. But not if it's a good idea either.

Presumably the user could choose to mark a folder as untrusted (or
toggle it trusted) through the relevant file-manager options.

We could set ~/Downloads and all of ~/QubesIncoming as Untrusted by
default and they could progressively "trust" incoming VMs by toggling
the option off on the VM folders.

The only problem I could see with that is if they want to trust a VM
that hasn't sent a file yet. The folder for that VM thus does not exist
yet...

Andrew Morgan

[Marek Marczykowski-Górecki]

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

But you can simply create it, right?

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

iQEcBAEBCAAGBQJYye7QAAoJENuP0xzK19csu4gH/jziq8pKCAcO4CaSNbwD182X
55iV2T8HUsRuJtDDCa/A7pA6BoXejdI1JljmaNRUNOqG8VP+hYFIQiOKh262odQl
PXtL9u2dJyWmvBaXSb7wQdXYmT1NaSdS30/WfWYJTttokcx5RjRlZu141HiXtuER
lDtbL45NKPdn+wa0S/7YKao647q3O3b2GDu1QPo1D9ibPtcqkTi4Yy+1wB1QKC3K
vvCn3DBy/Vfldjqn8XoQr1PWsT/CTNA3xh8+QVNGNBAqMmeGI0d0zSME2Papcmay
T76+cRjBy6KhPOmjfgeGj0F8R+3WeJe1Nl9pMsUKUCVRH4aLSgarS+8Oyz3gS0Q=
=ZCvB
-----END PGP SIGNATURE-----

[Andrew Morgan]

Yes, and with a daemon watching the ~/QubesIncoming folder, it should be
marked as untrusted by default whether the user or system created it.

Andrew Morgan