Convert to Trusted PDF failure - deletes original!

[cprise]

The Trusted PDF feature has stopped working for me. When I try to
convert this document:

https://www.vmware.com/pdf/convsa_55_guide.pdf

...not only do I not get a trusted version, but after a couple minutes
when the progress bar finishes the original copy gets deleted.

I'm launching the Trusted PDF converter from Files, within a stock appvm
running kernel 3.9.2 (default). The first time I noticed this happening
I was already running another dispvm (but closing it didn't make any
difference).

In this case I was lucky the pdf didn't contain any important or unique
data.

[Vincent Penquerc'h]

On 29/01/14 17:24, cprise wrote:
> The Trusted PDF feature has stopped working for me. When I try to
> convert this document:
>
> https://www.vmware.com/pdf/convsa_55_guide.pdf
>
> ...not only do I not get a trusted version, but after a couple minutes
> when the progress bar finishes the original copy gets deleted.

Does it get renamed to .convsa_55_guide.pdf ?

Any error output ?

[cprise]

Yes, it does rename it to a hidden file.

I don't see any errors for my appvm from the 3 logs listed by vm manager.

[Axon]

cprise:

IMHO, it should not rename the original to a hidden file.

When I first started using Qubes, I didn't know this either, and thought
the original had been deleted when I did an accidental conversion. (It's
very easy to misclick the option in the context menu.) I later
discovered by accident that it renames the originals to hidden files
when I was investigating why so much space was being used in an AppVM.

[Joanna Rutkowska]

The intention was to prevent the user from accidentally clicking the
untrusted file. Perhaps we can just move all the untrusted files to some
predefined user dir, such as ~/QubesUntrustedPDFs?

j.

[Axon]

Joanna Rutkowska:

Oh, I see. While preventing accidental opening is desirable, the best
solution I can think of is just to leave the untrusted file in place,
perhaps with "untrusted" added to the filename somehow. IMO, if the user
is going to accidentally open the untrusted file, that's most likely to
occur while the user is trying to convert it to a trusted PDF anyway.
Moving it to a predefined user dir would work, but
I suspect that would annoy many users (I could be wrong).

[Hakisho Nukama]

Why not modify the file extension or MIME type to something
$PDFviewer wouldn't open, like ".pdf-untrusted".

[Joanna Rutkowska]

I'm afraid the default mime handling in our Linux VMs is not
extenstion-based but content-based (like file command).

j.

[cprise]

This is probably new, because I have a pair of trusted/original PDFs
from a few weeks ago sitting in one of my vms.

I like the idea of ~/QubesUntrustedPDFs better than making the file
hidden. If you also put up a system notification mentioning that folder
when the conversion is completed then I think confusion can be avoided.

As for my current problem of the conversion not completing (or not
arriving back in the originating vm), all of my vms based on the
original qubes template have this problem. My vms based on my
'multimedia' template, with the RPMFusion repository added, are able to
start and complete a pdf conversion... however, vm manager then shows an
alert for dom0 saying "vm didn't give back all requested memory".

[cprise]

Some background on my templates:

1) The original template was generated by R2b3 at install time, but
encountered an error during or right after the generating process. It
seemed to work anyway.

2) The multimedia template was generated months earlier by R2b2 without
error and carried over to R2b3 by manually updating the qubes-specific
packages. It also has the RPMFusion repository added to it, and also an
improved font-rendering system (see my posts about "Infinality" font
rendering).

[Oleg Artemiev]

> I like the idea of ~/QubesUntrustedPDFs better than making the file hidden. If you also put up a system notification mentioning that folder when the conversion is completed then I think confusion can be avoided.

+1

> --
> You received this message because you are subscribed to the Google Groups
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Bye.Olli.
gpg --search-keys grey_olli
Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E
Blog keys (mostly in russian): http://grey-olli.livejournal.com/tag/

[tim.t...@gmail.com]

Well, if I rename a pdf file to some other extention it no longer opens, so I presume the MIME type isn't as important. The "proper" thing to do, would be to make evince(or whatever your pdf viewer of choice is) not automatically open .pdf files at all. Set it up so that it is bound to open only ".trusted-pdf" files... (perhaps with a random hash so that an attacker couldn't send you a non-trusted pdf with the trusted extension.)

Tim

[Joanna Rutkowska]

Yes, this is essentially part of the ticket #441 we have been planning
for some time and which is currently scheduled for R3:

http://wiki.qubes-os.org/trac/ticket/441

j.

[Vincent Diepeveen]

On Tue, 1 Apr 2014, tim.t...@gmail.com wrote:

> Well, if I rename a pdf file to some other extention it no longer opens, so I presume the MIME type isn't as important. The "proper" thing to do, would be to make evince(or whatever your pdf viewer of choice is) not automatically open .pdf files at all. Set it up so that it is bound to open only ".trusted-pdf" files... (perhaps with a random hash so that an attacker couldn't send you a non-trusted pdf with the trusted extension.)

Someone who's using such sorts of attacks has a pretty advanced
infrastructure at home encryption technical spoken. Means you need also
a safe function to hash stuff.

Tim the Lion, what sort of algorithm did you have in mind for a secure
hash?

You'll have to show up first with a new hashing algorithm that's better
than the current crap that's out there.

Better design that first.

If you already design such form of hash - also interesting thought is to
make it future proof - as in easy to be calculated using manycore
hardware. Obviously the famous manycores we've got now are built in gpu's.

The advantage of all the GPU's is that they also can multiply pretty fast
32 bits integers, so that allows for producing a deterministic and nearby
unbreakable hashing function at relative cheap number of clockcycles per byte.

> Tim

> --
> You received this message because you are subscribed to the Google Groups "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
> To post to this group, send email to qubes...@googlegroups.com.
> Visit this group at http://groups.google.com/group/qubes-users.

> For more options, visit https://groups.google.com/d/optout.
>

[Alex Dubois]

Alex

> On 2 Apr 2014, at 12:03, Vincent Diepeveen <di...@xs4all.nl> wrote:
>
>
>
>> On Tue, 1 Apr 2014, tim.t...@gmail.com wrote:
>>
>> Well, if I rename a pdf file to some other extention it no longer opens, so I presume the MIME type isn't as important. The "proper" thing to do, would be to make evince(or whatever your pdf viewer of choice is) not automatically open .pdf files at all. Set it up so that it is bound to open only ".trusted-pdf" files... (perhaps with a random hash so that an attacker couldn't send you a non-trusted pdf with the trusted extension.)
>
> Someone who's using such sorts of attacks has a pretty advanced infrastructure at home encryption technical spoken. Means you need also
> a safe function to hash stuff.
>
> Tim the Lion, what sort of algorithm did you have in mind for a secure hash?
>
> You'll have to show up first with a new hashing algorithm that's better than the current crap that's out there.
>
> Better design that first.
>
> If you already design such form of hash - also interesting thought is to make it future proof - as in easy to be calculated using manycore hardware. Obviously the famous manycores we've got now are built in gpu's.
>
> The advantage of all the GPU's is that they also can multiply pretty fast 32 bits integers, so that allows for producing a deterministic and nearby unbreakable hashing function at relative cheap number of clockcycles per byte.

Maybe a memory hard problem?

[tim.t...@gmail.com]

I guess my responce would be, that I was just making a quip remark, and in truth I think that the idea of "converting to a trusted PDF" is kind of weird. If you don't trust the thing, why not just read it in the DispVM and aviod handling it at all in a sensetive context?

Tim

[Ph.T]

On Wed, Apr 2, 2014 at 11:35 AM, <tim.t...@gmail.com> wrote:

... in truth I think that the idea of "converting to a trusted PDF" is kind of weird.  If you don't trust the thing, why not just read it in the DispVM and avoid handling it at all in a sensitive context?

. some trojan'd pdf's will slow your vm down;

it would be convenient to convert those pdf's .