[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    Re: [qubes-devel] Re: [GSoC] Qubes-MIME-Handlers Weekly Progress Report #3
From:       Marek =?utf-8?Q?Marczykowski-G=C3=B3recki?= <marmarek () invisiblethingslab ! com>
Date:       2017-06-22 9:08:04
Message-ID: 20170622090804.GY1268 () mail-itl
[Download RAW message or body]

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

On Thu, Jun 22, 2017 at 01:50:56AM -0700, Andrew Morgan wrote:
> On 06/22/2017 01:11 AM, Marek Marczykowski-Górecki wrote:
> > An idea: mark folder untrusted also using xattr. Then it will be immune
> > to folder rename. And checking file inside would require "just" checking
> > directories up in the tree.
> 
> This is true, however would require a Nautilus patch as the way we
> currently tell Nautilus that a file is untrusted is mostly due to the
> fact that it is unreadable (and thus has a special MIME-type).

No no, I was talking about marking directory _in addition to_ marking
files - i.e. what directories should be handled by inotify-handling
daemon.

But as I'm thinking more about it, it would be less convenient, as you
can't easily get list of directories with given xattr, without looking
up all all the user home. And the same about noticing new directories.

So, a file with path list looks like a better idea.

> > > The location of the untrusted-folders file. This file keeps track of
> > > the folder paths that are untrusted, and is used by the daemon. Even
> > > after reading the Qubes Contribution Guidelines I'm still not sure where
> > > to put this. /usr/share/qubes seems to be the apt location but there's
> > > not much in there already. Marek?
> > 
> > /usr/share should not be modified at runtime. As we're talking about
> > configuration, it's better to put it in /etc/qubes/ (defaults for all
> > VMs based on given template) and ~/.config/qubes/ (VM local list) -
> > merge lists from those two places. And qvm-trust tool should modify the
> > later.
> 
> Good idea, makes management quite simple.
> 
> > Merging two lists means you need some way to exclude directory (for
> > example generally ~/Downloads configured as untrusted, but you want to
> > exclude it in "untrusted" VM - to open downloaded files directly in the
> > VM there).
> 
> Yeah, you'd need to clarify "trusted" as something other than the
> default, which is fine. There could be 3 states: trusted, untrusted and
> undefined. However this may make things more confusing for the user.

I was thinking about excluding whole directories, not subset of them.
Let me explain on example:

/etc/qubes/always-open-in-dispvm.list:

    /home/user/Downloads
    /home/user/QubesIncoming

untrusted:/home/user/.config/qubes/always-open-in-dispvm.list:

    -/home/user/Downloads

So, files in ~/Downloads would be opened in DispVM everywhere besides
"untrusted" VM. But this excluding works only for entries earlier
included in the list, specifically "-/home/user/xyz" or
"-/home/user/Downloads/some-subdir" does nothing because none of them
were included before.
Yes - we don't want "trusted" subdirectory inside "untrusted" one.

> > Clarification: currently there is no way to mark file as "trusted" if
> > the directory is "untrusted" (assuming file marking daemon is working),
> > right? I think this is a good thing.
> > 
> 
> A file is "trusted" if it doesn't have the 'user.qubes.untrusted' xattr,
> however if we do implement checking based on 'walking up' the file path
> then this would be true.

Lets move this to the other thread (Joanna's response).

> In the current design, you can place a file into an untrusted folder,
> it'll be marked untrusted by the daemon, then you can mark the file as
> trusted again and it will remain that way inside the untrusted folder.
> 
> That may be useful to users who want to keep certain files in their
> ~/Downloads folder without having to open them in a DispVM every time.

IMO the user should move the file out of Downloads first to have this
effect.

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

iQEcBAEBCAAGBQJZS4j1AAoJENuP0xzK19cs0igH/jkOHbO0V++L80QRRCF1pyAw
M6Viwx1S+83O4/Q8EkqdduzdzNYI2PBXCBdgEQMWAU/qOxGswI9YSVVOERvSSmK7
HWblktv4GBJ4gtZkt/Z/il/j//vdhs1Vbfz1aW2fnllk22CTa8BiOFd6wiWUulaa
vPm+YLLilV0CXNOoJ9+iVW9ACpi+08huVvUrNTkIQoLmiZsU0Uh6di8z8JdHpiaX
0IKDIVTEdGIh8MTZYg9Y5H3+BoHvLcQxXr7B15rWXne9K/docVElW3V7Db+H1K5s
Gc+a1ZPvTjkxMW/mzjhCzvbeJXeV2t7hGRWt26eRi8WnVSQxYiS70lViKoEgVT8=
=6pDU
-----END PGP SIGNATURE-----

-- 
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 qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/20170622090804.GY1268%40mail-itl. For \
more options, visit https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]