3 ms·

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing

by lima 2y ago

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.

mjevans 2y ago
Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern. A single fixed path for the temporary input file means only one copy of the converter can run at a time (unless it's in a sandbox, which wasn't clear from the context). A PID specific tempfile or, better, use a standard 'make a new temp file name so there's not a collision' utility, would allow parallel conversions.
- apyrgiotis 2y ago
  Hey, Dangerzone dev here. Just wanted to say that the temporary input file is actually within a sandbox - and there's one sandbox per file - so there's no collision with other files in the host. > Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern. Yep, that's something we cover in our about page. We process the untrusted document in a gVisor sandbox, that runs within a hardened Linux container, that runs within a Docker Desktop VM (in Windows/macOS). And yet, that doesn't mean that Dangerzone can't get hacked by a determined (possibly state-backed) attacker. So yeah, you have a point. At the same time, using tools like this raises the "you must be THIS determined to enter" bar. This means attackers must spend much more money, time, expertise, 0-days, etc. These resources are finite, so more people are protected as a net result, even if we can't protect everyone. That's the way I see it at least.
  - fl0id 2y ago
    very good answer :)

3 ms·

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing

by lima 2y ago

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.

mjevans 2y ago
Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern. A single fixed path for the temporary input file means only one copy of the converter can run at a time (unless it's in a sandbox, which wasn't clear from the context). A PID specific tempfile or, better, use a standard 'make a new temp file name so there's not a collision' utility, would allow parallel conversions.
- apyrgiotis 2y ago
  Hey, Dangerzone dev here. Just wanted to say that the temporary input file is actually within a sandbox - and there's one sandbox per file - so there's no collision with other files in the host. > Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern. Yep, that's something we cover in our about page. We process the untrusted document in a gVisor sandbox, that runs within a hardened Linux container, that runs within a Docker Desktop VM (in Windows/macOS). And yet, that doesn't mean that Dangerzone can't get hacked by a determined (possibly state-backed) attacker. So yeah, you have a point. At the same time, using tools like this raises the "you must be THIS determined to enter" bar. This means attackers must spend much more money, time, expertise, 0-days, etc. These resources are finite, so more people are protected as a net result, even if we can't protect everyone. That's the way I see it at least.
  - fl0id 2y ago
    very good answer :)