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