Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Qubes Air: Generalizing the Qubes Architecture

qubes-os.org

Post reply on HN
Print view View original

51–60 of 68 posts

Re: Qubes Air: Generalizing the Qubes Architecture

#51

Post by nickpsecurity »

blattimwind wrote: post #46
nickpsecurity wrote: post #43

Earlier quoted context omitted.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

> 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…

Oh, that's neat it's what they're doing. Far as secure PDF reader, you can definitely reduce risks it poses with mitigations which reduce headaches when they don't reduce attacks. Those I was thinking of are doing it with acceptable overheads these days. On the far end, the CPU solution already compiles legacy C to run capability-secure on FreeBSD with OS and CPU available to download and run. Just gotta buy the board which has other uses.

So, there's more possibilities to explore on top of these existing solutions.

Re: Qubes Air: Generalizing the Qubes Architecture

#52

Post by [deleted] »

kakarot wrote: post #31
eptcyka wrote: post #25

Earlier quoted context omitted.

Passing through GPUs is problematic, as it's a massive attack surface.

It's unavoidable for me. It provides no drawback for users who don't utilize it, and the alternative is me remaining with KVM which is a vastly larger attack surface, so your argument defeats itself.

[deleted]

Re: Qubes Air: Generalizing the Qubes Architecture

#53

Post by nickpsecurity »

tptacek wrote: post #44
nickpsecurity wrote: post #43

Earlier quoted context omitted.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

Your "first solution" would be to take a de novo PDF implementation written in C, "compile it with something that makes it memory-safe", and then port it to an L4 microkernel. Maybe bust out some HDL and get parts of it deployed directly on to FPGA. Got it.

I said a separation kernel like the FOSS projects and commercial products dating back to 2005 I told Joanna about on Qubes mailing list which were compartmentalizing things on security-focused kernels. Aside from small TCB, they have optional mitifations for storage and timing channels. Aside from isolation, a standard practice on embedded side was including safe subsets of Java or Ada running right on the kernel to implement specific components more safely. So, basically just what was standard, deployed practice in high security over a decade ago.

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.

Re: Qubes Air: Generalizing the Qubes Architecture

#54

Post by tptacek »

nickpsecurity wrote: post #53
tptacek wrote: post #44

Earlier quoted context omitted.

Your "first solution" would be to take a de novo PDF implementation written in C, "compile it with something that makes it memory-safe", and then port it to an L4 microkernel. Maybe bust out some HDL and get parts of it deployed directly on to FPGA. Got it.

I said a separation kernel like the FOSS projects and commercial products dating back to 2005 I told Joanna about on Qubes mailing list which were compartmentalizing things on security-focused kernels. Aside from small TCB, they have optional mitifations for storage and timing channels. Aside from isolation, a standard practice on embedded side was including safe subsets of Java or Ada running right on the kernel to…

Oh, and a safe subset of Java or Ada in the kernel. Well, that clears it all up.

Re: Qubes Air: Generalizing the Qubes Architecture

#55

Post by nickpsecurity »

tptacek wrote: post #54
nickpsecurity wrote: post #53

Earlier quoted context omitted.

I said a separation kernel like the FOSS projects and commercial products dating back to 2005 I told Joanna about on Qubes mailing list which were compartmentalizing things on security-focused kernels. Aside from small TCB, they have optional mitifations for storage and timing channels. Aside from isolation, a standard practice on embedded side was including safe subsets of Java or Ada running right on the kernel to…

Oh, and a safe subset of Java or Ada in the kernel. Well, that clears it all up.

"safe subsets of Java or Ada running right on the kernel to implement specific components more safely. "

"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.

Re: Qubes Air: Generalizing the Qubes Architecture

#56

Post by wglb »

nickpsecurity wrote: post #43
dhimes wrote: post #36

Earlier quoted context omitted.

Or weinzierl could print them and possibly rescan for further distribution.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

compiling it with something that makes it memory-safe

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?

Re: Qubes Air: Generalizing the Qubes Architecture

#57

Post by pcwalton »

nickpsecurity wrote: post #43
dhimes wrote: post #36

Earlier quoted context omitted.

Or weinzierl could print them and possibly rescan for further distribution.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

Or, you know, you could use pdf.js, which has two advantages: (1) it already exists; (2) it can exist, unlike your proposal, which involves using a nonexistent memory-safe C++ compiler.

Re: Qubes Air: Generalizing the Qubes Architecture

#58

Post by pcwalton »

blattimwind wrote: post #46
nickpsecurity wrote: post #43

Earlier quoted context omitted.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

> 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…

> 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.

pdf.js exists!

Re: Qubes Air: Generalizing the Qubes Architecture

#59

Post by pcwalton »

wglb wrote: post #56
nickpsecurity wrote: post #43

Earlier quoted context omitted.

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. This might even be batched on simple hardware which itself has lower attack surface. Later on secure…

compiling it with something that makes it memory-safe 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?

It's nonsense. If it were possible to make C++ memory-safe with a special compiler, it would have been done long ago.

Re: Qubes Air: Generalizing the Qubes Architecture

#60

Post by nickpsecurity »

pcwalton wrote: post #58
blattimwind wrote: post #46

Earlier quoted context omitted.

> 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…

> 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. pdf.js exists!

I thought pdf.js was a Javascript application in a browser on a full OS with all the risks that come with that versus a memory-safe, native code in a deprivileged partition or container. Web tech isnt my strong area do I could be wrong. Do correct if it's not a browser or JS tech built in unsafe language.

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.

Post reply on HN