[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:       Joanna Rutkowska <joanna () invisiblethingslab ! com>
Date:       2017-06-22 9:00:26
Message-ID: 20170622090026.GF9559 () work-mutt
[Download RAW message or body]

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

On Thu, Jun 22, 2017 at 01:32:32AM -0700, Andrew Morgan wrote:
> On 06/22/2017 01:01 AM, Joanna Rutkowska wrote:
> > 
> > On Wed, Jun 21, 2017 at 11:15:30PM -0700, Andrew Morgan wrote:
> > > Hey everybody, another progress report for ya.
> > 
> > > As always, you can find the report with screenshots here:
> > > https://blog.amorgan.xyz/gsoc-weekly-progress-report-3.html
> > 
> > > Otherwise the text-only version is reproduced below:
> > 
> > 
> > Hello, a few quick questions and comments:
> > 
> > > ---
> > 
> > > Good news everyone! The code base has been completely refactored from
> > > multiple scripts with duplicated code into one lean python cli tool. All
> > > the other scripts simply make use of this now.
> > 
> > > Additionally, 90% of the bash in the project has now been replaced with
> > > python, which should allow more portability and more maintainable code.
> > 
> > > # New CLI Tool
> > 
> > > This new utility is called qvm-trust, and can be used in the following
> > > manner:
> > 
> > 
> > I think it'd be better to name the tool qvm-file-trust.
> 
> Can do, though the tool can also handle folders. I presume that still works?
> 

But, at the end of the day, it's all about determining trustworthiness of files,
right? So, I think using 'file' is justified.

> > 
> > > $ qvm-trust -h
> > > usage: qvm-trust [-h] [-c] [-t] [-u] [-q] path [path ...]
> > 
> > > Set or check file/folder trust levels.
> > 
> > > positional arguments:
> > > path             a folder or file path
> > 
> > > optional arguments:
> > > -h, --help       show this help message and exit
> > > -c, --check      Check whether a file or folder is trusted
> > > -t, --trusted    Set files or folders as trusted
> > > -u, --untrusted  Set files or folders as untrusted
> > > -q, --quiet      Do not print to stdout
> > 
> > > Some example usage includes: setting a file as untrusted:
> > 
> > > $ qvm-trust --untrusted ./leaked-documents.pdf
> > 
> > 
> > So, where is this information kept for individual files? If somebody sent me a
> > file (e.g. via email attachment or I download it from the Web), can they also
> > make the file "trusted"? In your previous post you mentioned the use of extended
> > attributes -- how do you make sure that if I get e.g. a tgz-ed or cpio-ed
> > archive, then unpack, that there will be no attacker-controlled attributes
> > there, which would trick me into opening these (untrusted) files locally,
> > instead of via DispVM?
> 
> For individual files an xattr [1][2] with key 'user.qubes.untrusted' and
> value 'true' is added to the file.
> 
> For both tar and cpio, once a file is added and extracted from an
> archive it no longer carries the xattr and thus is set back to the
> default of trusted. This is also true when uploading/downloading from
> the web as attributes are part of the local filesystem and not the file
> itself.
> 
> > 
> > > **Actually while writing this I just thought... we could combine 2
> > > and 3 together and just append '.untrusted' to untrusted file types,
> > > then register the '.untrusted' file extension with our desktop handler.
> > > Hm... will try that right after I post this :)**
> > 
> > 
> > This gives control into the hands of attacker, e.g. to force opening the crafted
> > file in a DispVM. While this seems innocent (esp. compared to the inverse
> > scenario if we wanted to use '.trusted' exception), still this feels somehow
> > wrong.
> 
> Yes... I agree and likely got a bit too ahead of myself with that solution.
> 
> I'd also like to clarify on the above, Dolphin seems to only determine
> the file-type through reading the file if it is not given a known
> extension such as .txt or .pdf. If it is given a known extension, then
> it's recognized as such, no matter what.
> 
> Interestingly, even after setting up a handler for an '.untrusted'
> extension, it doesn't treat this as a recognized extension and instead
> reverts back to checking the file contents for their MIME-type.
> 
> > 
> > > 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?
> > 
> > 
> > Ideally we want to keep it somehow hidden from the user and protected against
> > accidental modifications. 
> 
> I've also just realized it will need to be stored in $HOME or /rw/ if
> it's to remain persistent across reboots.
> 
> > E.g. should be very hard for the user to (get convinced to) copy/move some files \
> > there.
> 
> Right, but still needs to be editable by the local user. Not sure if
> /rw/ is sufficient. We can also make it a hidden file.
> 
> Or even better, `chmod 0` it as well.
> 
> > 
> > > # Going Forward
> > 
> > > We're currently heading into week 2 of 4 of what was supposed to be
> > > patching the file managers, however now that it seems that's no longer
> > > necessary, we're pretty much ahead of schedule! After Dolphin is fixed
> > > up, I'll create a daemon to monitor untrusted folders and their
> > > contents. If a new file is placed or created inside them, they'll
> > > instantly be marked as untrusted.
> > 
> > 
> > Hm, that's exposing additional attack surface on the VM, so don't like. Also,
> > again, how are files going to be marked?
> 
> We could set all files within a folder to untrusted when a folder is
> marked as such, but I'm not sure of any other way to keep it
> consistently updated without a daemon, unless there is an existing Qubes
> component that could be modified to take care of this?
> 
> All the program would need to do is:
> 
> Place inotify listeners on each folder listed in the tracking file.
> On an inotify NEW event, mark the new file as untrusted.
> 
> The only real attack I could see is again changing the contents of the
> tracking file, but then again a malicious actor could edit many files in
> $HOME and have a negative effect on the VM.
> 
> Andrew Morgan
> 
> [1]: https://en.wikipedia.org/wiki/Extended_file_attributes
> [2]: http://www.freedesktop.org/wiki/CommonExtendedAttributes
> 

Ideally, I think the evaluation of trustworthiness should be like this:

1. All files are considered _untrusted_ unless we check all the rules below, and
none of them identifies the file as _untrusted_,

2. If the file is under a path which contains pre-defined untrusted string (such
as...  "untrusted", ALWAYS case _insensitive_ match), the file is untrusted, no
matter what xattrs might be saying. E.g. the file might be from some FAT
filesystem attached to the VM via qvm-block or qvm-usb and we still want to
catch it.

3. If the file has xattr saying it's untrusted.

(4. If none of the above, then consider it trusted.)

I somehow don't like the solution which offloads everything to xattrs, because:
1. Some filesytems might not support it (e.g. FAT-based stick?), or have bugs,
2. Whatever daemon we might rely on marking the files as untrusted with per-file
attributes (e.g. whenever they land in ~/Downloads) might accidentally (or less
accidentally) crash (or be made to crash).

joanna.
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJZS4cpAAoJEDOT2L8N3GcY/fwQAJKrYzy/n4HeGsqwqT102e2R
Wt9qbUWJbzDH+60O1beclAt7EtfnoWfLlDSVtJxDSMki6zNUK2H3p+OJRfK9MANG
9Lq8v/rRu4FQA9n/wI9gCOj2JgnlRFKwUMlTTjlAZ7CWcPVN9TmlFybg0yhFdw0/
9YeIgFdwoSvfpmnN+4IDK47BWy7zctpF2GF+cPaMG8xeh53nX2wHASUal/qCF6Sz
nxcppGiijlfnfuXdwC1nDNVqpS4UN+RJG8E4uRFC5lkEgejx45p3wwMPduVh9ogD
0ZbOr7vzNda0g6DoFw+RQLyk71tbRPAuvCDq/+1AZXqjJX8V2ccqW6Gwj2r4fGxm
ro/nzZ7zHiPIxxs564Sgt7SIinUdiuBUjVdr143pXP+1yPLY+off+PxAcX1toLMz
DmuxQljK0HHPHuoOi2MnATnxBNqpYR/GiDB5ac+vvPIR5C42IonZiMPIsZbDioZr
5efavJ7RSX3R4dJfkKyiP/ZguBZ8hpqLQoDXM8+907Xv3iT8uK6mWabqpODbiqUb
UcNgIjJaQ++x/ShaQAAv2jVs1m4a/WzkLztiIcdRldkWTqxGBJforHdY8sQYScMi
AnauIvYgN2cE416MFnNUtMPrGxOKFN0j0I2D4KAVh8goM8/Qz1ahgnadsP8nEDHu
iuz8iUM3a2XUtAyR+OyU
=Vuq1
-----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/20170622090026.GF9559%40work-mutt. For \
more options, visit https://groups.google.com/d/optout.


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