Closed deeplow closed 3 years ago
A UX improvement may be to inform the user there is a problem with the policy. This would make life easier when the qvm-convert-pdf
is used with any other distro template since users will know what to look for in order to fix it.
Looks to be due to Debian patches in 6.9.10.23+dfsg-2.1+deb10u1 which also addressed around 50 CVEs (changelog: Thu, 25 Jun 2020):
Author: Steve Beattie steve.beattie@canonical.com Subject: disable ghostscript handled formats based on -SAFER insecurity
Based on Tavis Ormandy's Recommendations updated: 2019-11-11
+ <!-- disable ghostscript format types -->
+ <policy domain="coder" rights="none" pattern="PS" />
+ <policy domain="coder" rights="none" pattern="PS2" />
+ <policy domain="coder" rights="none" pattern="PS3" />
+ <policy domain="coder" rights="none" pattern="EPS" />
+ <policy domain="coder" rights="none" pattern="PDF" />
+ <policy domain="coder" rights="none" pattern="XPS" />
In a generic case it looks like a good idea to disable those coders. But here we operate explicitly on a safe input with no way to inject any code for ghostscript to parse. Setting rights to "write" for PDF coder should be safe in context of qvm-convert-pdf, but in generic case may open the user to some ImageMagick vulnerabilities...
Perhaps a better option is to look at graphicsmagick instead? #5009
But here we operate explicitly on a safe input with no way to inject any code for ghostscript to parse.
@marmarek Exactly. So ideally the there would de the default policy (strict) to prevent user foot-shooting mistakes and then "PDF write" policy specific to the qvm-convert-pdf. But I'm not sure that is possible on imagemagick. (I haven't looked to much into it)
Looks to be due to Debian patches in 6.9.10.23+dfsg-2.1+deb10u1 which also addressed around 50 CVEs
@icequbes1 So in this case here, debian has a stricter policy than fedora. Doesn't this then mean that fedora is still exposed to these CVEs? Or is it because of the outdated Debian software? Maybe I'm missing something here.
In R4.1, if a PDF file is converted to a trusted PDF via the corresponding function, the dispvm for the conversion is created, performs the conversion, but then stays running and has to be shutdown manually.
@deeplow This works for me 210610. Can you test again?
@deeplow This works for me 210610. Can you test again?
It seems to be working for me now.
@deeplow This works for me 210610.
Can you test again?
It seems to be working for me now.
Closing this as resolved. If you believe the issue is not yet resolved, or if anyone is still affected by this issue, please leave a comment, and we'll be happy to reopen this. Thank you.
On QubesR4.1, the situation is unchanged: The conversion succeeds, but the dispvm does not close and has to be shut down manually.
Even after applying all current updates to dom0 and the debian template, the situation is unchanged. The zombie dispvm sems to be in a somewhat queer state, as shutting it down from the Qube manager crashes the Qube manager.
On Sun, Jun 13, 2021 at 03:07:59AM -0700, Andrew David Wong wrote:
Reopened #6130.
This is a separate 4.1 issue, and not Debian specific.
Even after applying all current updates to dom0 and the debian template, the situation is unchanged. The zombie dispvm sems to be in a somewhat queer state, as shutting it down from the Qube manager crashes the Qube manager.
Would you be willing to provide a backtrace? qubes-manager crashing is an unrelated bug, though.
On Sun, Jun 13, 2021 at 03:07:59AM -0700, Andrew David Wong wrote:
Reopened #6130.
This is a separate 4.1 issue, and not Debian specific.
I'm guessing "this" refers to @GWeck 's comments, which prompted me to reopen this issue? And I'm guessing you're saying that the issue on which we're commenting is actually still resolved and that @GWeck is experiencing a separate bug that should be reported in a separate issue? Re-closing as resolved, then...
Qubes OS version
R4.0 and R4.1
Affected component(s) or functionality
Brief summary
Running
qvm-convert-pdf
fails on debian-10 based AppVMs due to a strict default ImageMagick policy (/etc/ImageMagick-6/policy.xml
)I also tested with various combinations of fedora and debian distros:
It works on fedora because it has a less strict default policy.
To Reproduce
Steps to reproduce the behavior:
qvm-convert-pdf file.pdf
(or whatever pdf file you have)Expected behavior
Actual behavior
Screenshots
Additional context
The discussion that originated this came from the forum.
It has been reproduced by @GWeck and Clarawolf (kudos to Clara for starting the thread and GWeck for reproducing it)
Solutions you've tried
I've managed to solve this by removing the following line from the policy:
But it should also be possible to replace that with:
So the final fix should be changing the default ImageMagick policy (
/etc/ImageMagick-6/policy.xml
) that ships with the qubes debian-10 template.From my understanding, this change of policy does NOT affect the security of of the conversion to trusted.
Relevant documentation you've consulted
Related, non-duplicate issues
none