My use case is examining, cleaning and possibly distributing application letters and CVs. If you have to read job application letters, the advice to just open files from people you trust, just doesn’t work. The amount of untargeted malware we receive through this channel is considerable. We had targeted attacks too.
I’ve known about Qubes OS for a long time but interestingly the advice to use it for all processing of application letters didn’t come from my tech circles but from a recruiter.
Given the strict laws about data retention in my jurisdiction (Germany) a cloud solution (short of homomorphic encryption) probably isn’t going to work for me. The idea of using discrete devices sounds interesting though.
For fun, though, I'll dust off an old concept since you're talking printing. One might start by printing them to a virtual screen like in Nitpicker GUI with the untrusted reader. Aside from isolation, there could be a feature to convert what's on the virtual screen or page into a compressed image. A PDF with N pages becomes a zip of N images or a single image of some size. That itself could be distributed to run in the trusted, safe viewers we already should have, right? ;) It might also be run back through similarly-deprivileged OCR to turn into a safer format. Gotta eyeball it if doing it that way. That said, there are fonts that work well with OCR that it might be converted to as part of image production if OCR is the goal in the first place.
Could be a fun, little project teaching folks about a number of topics at once.
Optionally, I also pointed out people interested in developing solutions have options available now for safety or security on CPU side, too. They can do software, hardware, mix of both, whatever suits their purposes.
"a safe subset of Java or Ada in the kernel."
Done here since you're arguing against points Im not making. For anyone your strawman confused, the specific components are user-mode apps running on a separation kernel to minimize privilege. Not just piles of extra code in some kernel.
Which is literally what Qubes "Convert to trusted PDF" does.
> My first solution would be improving reader security by starting with one with decent code (Espie suggested MuPDF), compiling it with something that makes it memory-safe, and running it in a sandbox on separation kernel (eg Genode or Muen). Then, a memory-safe conversion tool turns it into something more trustworthy.
It would of course be preferable to have a secure PDF reader to begin with, but the complexities of the PDF format doesn't isn't really conducive to that.
So, there's more possibilities to explore on top of these existing solutions.
And it's a little strange your reply to memory-safe code for a PDF reader is that an "unsafe one exists, just use it" when you or your colleagues are currently applying my recommendation to the browser hosting it via Rust and Quantum.
You're doing one thing that matches the language part of my recommendation while saying we should do the opposite about a type of program that's similarly high risk. Quite the contradiction.
Now, you do in this thread if it involves a risky format attackers love. I dont. I think complex languages running in large apps increase attack surface. So, I still recommend strong sandboxing whatever parser/renderer one uses plus developers in security-focused projects (eg Qubes) using compilers or languages offering safety if having resources to spare. Everyone contributing a little gives us more building blocks over time.
And far as your other comment, there are always new ways to turn C code safe or secure being developed. C++ might also be able to use them via a C++ to C compiler but has stuff like SaferCPlusPlus to help. For C, options to attempt include Softbound+CETS, SAFEcode, Code Pointer Integrity, and dataflow integrity. At least three are FOSS with one I havent checked yet. So, they exist. They could also be in even better shape if security tool builders put more time in them.
By the way, SaferCPlusPlus is not memory safe, and porting a PDF rendering code base to use it would be about as much work as rewriting the renderer in a safe language.
Also, Rust has been designed to make parallel code safe, something a GC can't give you.
> So, I still recommend strong sandboxing whatever parser/renderer one uses plus developers in security-focused projects (eg Qubes)
> And far as your other comment, there are always new ways to turn C code safe or secure being developed. C++ might also be able to use them via a C++ to C compiler but has stuff like SaferCPlusPlus to help. For C, options to attempt include Softbound+CETS, SAFEcode, Code Pointer Integrity, and dataflow integrity. At least three are FOSS with one I havent checked yet. So, they exist. They could also be in even better shape if security tool builders put more time in them.
Isn't it true that there is a bit more work to do to a program to make it memory safe than just recompiling?
Like if the original is in C, recompiling it in C++ won't whisk away unsafe memory access without significant architectural rework, no?