What dangers does dangerzone protect against?

[spookylukey]

The README doesn't actually say what this protects against. I can imagine some things, but without a list, you are either left not understanding why you would even need this, or you are left with a false sense of security thinking you are protected against things you are not protected against.

For example, here is a list of dangers that may or may not be included:

• memory exhaustion
• remote tracking over a network
• macros
• other unexpected file system/resource access (what exactly?)
• hidden messages in alpha channels
• hidden messages in lower bits of images
• improperly scrubbed data still present "underneath" (for vector based formats)
• more??

[micahflee]

In the next few days I will publish a detailed blog post about dangerzone that answers all these questions. But in short, you can think of dangerzone as taking the original document, printing it, scanning it, then OCRing it -- except all done in software.

So it will remove everything from the document except for visual watermarks. It can't remove printer dots, probably can't remove hidden messages in bits of each pixel, can't remove stuff like different kerning for different copies of a doc. But it will remove everything else (including metadata).

[techybuddha]

It stops us from building highways.

Death occurs on highways.

[CommonLoon102]

Does it protect against exploiting vulnerabilities in the kernel?

[CommonLoon102]

It would be useful to tell the users to turn off thumbnail view in their OS, otherwise the game is already lost if they navigate into the folder where the malicious PDF resides. (Even then, it is not 100% percent that the thumbnail is not generated in the background, maybe it is just not shown, maybe it is easier to just not use any GUI desktop environment.)

[rarecoil]

@micahflee i saw this on hacker news earlier. thank you for working to build some new tooling for dealing with a pretty unreliable format in a system that looks to be pretty easy to use.

with a tool like this that is meant to handle potentially hostile data, i believe it is important to explain the threat model for this tool in the README, similar to projects like qubes and whonix. people can hurt themselves trusting a tool without understanding what threats it is actually meant to protect them against and what the attacks against the system are.

in this current proof of concept, dangerzone is expecting a lot out of docker's default configuration, with the only change i saw from a default docker run being to disable network access. this leaves a lot of attack surface up to default configurations, and i believe that tool advertised to handle hostile data should be built with a pretty paranoid threat model in mind.

for a targeted or relatively sophisticated adversary class, a docker container in a relatively default state should be best assumed a fragile security boundary to start. there's a good amount of hardening that can still be had. this is a rabbit hole of hardening for sure; there are hardware resource constraints that can be placed on the container for denial of service, sign the default image, use various --security-opt features such as no-new-privileges (easy) or seccomp for syscall whitelisting, to name a few.

in my opinion, parts of the cis docker benchmark and the above documentation is a good minimum baseline to target and explain in the threat model.

[micahflee]

I published a blog post (and linked to it from the readme) that goes into much more detail about how dangerzone works: https://tech.firstlook.media/dangerzone-working-with-suspicious-documents-without-getting-hacked

And @rarecoil thanks for the feedback. I've opened a new issue about container hardening #52

[fabionatali]

I was redirected to Dangerzone from the now discontinued PDF Redact Tools.

As the name implies, "PDF Redact Tools helps with securely redacting and stripping metadata from documents before publishing" (source).

If redacting metadata falls within Dangerzone's scope, it might be useful to state it on the project webpage and its readme file. To some extent, metadata redaction is implied in the "How it works" section but an explicit mention might be helpful?