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