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

61–68 of 68 posts

Re: Qubes Air: Generalizing the Qubes Architecture

#61

Post by pcwalton »

nickpsecurity wrote: post #60
pcwalton wrote: post #58

Earlier quoted context omitted.

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

JavaScript is a memory-safe language!

Re: Qubes Air: Generalizing the Qubes Architecture

#62

Post by kakarot »

ecesena wrote: post #45
kakarot wrote: post #18

Earlier quoted context omitted.

I think the idea is you just buck up and pay the cloud fees. If you follow Qubes / ITL, you would know that they are hardly a "startup" as a decade-old company, and they have been experimenting with enterprise-level support. If they can find a home in the enterprise market, it will at least give them enough cashflow to continue developing Qubes for the foreseeable future. Besides, I imagine Joanna Rutkowska's opinion…

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop. All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing, and/or does an ico because I see a great incentive to run nodes of the cloud (because qubes utself provides all the building block for trust). > If you follow Qubes I…

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop.

All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing

That's strange, because the first sentence in your OP is:

Qubes would make for a great startup and, given the time, prob a very successful ICO.

Re: Qubes Air: Generalizing the Qubes Architecture

#63

Post by nickpsecurity »

pcwalton wrote: post #61
nickpsecurity wrote: post #60

Earlier quoted context omitted.

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…

JavaScript is a memory-safe language!

This is really confusing for me since you keep implying JavaScript is all we need for safe, secure, efficient, and/or low-TCB apps like this one parsing and rendering PDF's. Yet, you arent rewriting Firefox parsers and renderers in Javascript: you are using a new language with the properties I just named. Properties shared with safe C/Java/Ada subsets used in embedded but with even more safety added (borrow-checker). That's probably because you didnt trust Javascript to do the job efficienty, securely, and without leaks.

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.

All Im saying on this since you seem set on Javascript for efficient, secure apps. We arent going to agree on that premise.

Re: Qubes Air: Generalizing the Qubes Architecture

#64

Post by pcwalton »

nickpsecurity wrote: post #63
pcwalton wrote: post #61

Earlier quoted context omitted.

JavaScript is a memory-safe language!

This is really confusing for me since you keep implying JavaScript is all we need for safe, secure, efficient, and/or low-TCB apps like this one parsing and rendering PDF's. Yet, you arent rewriting Firefox parsers and renderers in Javascript: you are using a new language with the properties I just named. Properties shared with safe C/Java/Ada subsets used in embedded but with even more safety added (borrow-checker).…

I'm not saying pdf.js is fast. I'm saying that it's fast enough to be a useful tool to read most PDFs securely (which in fact millions of Firefox users do!), and it has the large advantage of actually existing, unlike complex schemes involving vaporware compilers and Ada in the kernel. (If you care about fast secure PDF viewing, write a new PDF renderer in Rust or Java or Go or whatever. This doesn't have to be a complex problem.)

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.

Re: Qubes Air: Generalizing the Qubes Architecture

#65

Post by littlestymaar »

nickpsecurity wrote: post #63
pcwalton wrote: post #61

Earlier quoted context omitted.

JavaScript is a memory-safe language!

This is really confusing for me since you keep implying JavaScript is all we need for safe, secure, efficient, and/or low-TCB apps like this one parsing and rendering PDF's. Yet, you arent rewriting Firefox parsers and renderers in Javascript: you are using a new language with the properties I just named. Properties shared with safe C/Java/Ada subsets used in embedded but with even more safety added (borrow-checker).…

> This is really confusing for me since you keep implying JavaScript is all we need for safe, secure, efficient, and/or low-TCB apps like this one parsing and rendering PDF's. Yet, you arent rewriting Firefox parsers and renderers in Javascript: you are using a new language with the properties I just named. […] That's probably because you didnt trust Javascript to do the job efficienty, securely, and without leaks.

JavaScript is a memory-safe language thanks to a well known runtime trick called a «garbage collector» … Until Rust came, GC was the only viable way to have a memory-safe language. Unfortunately, it has important performance drawbacks which makes it unsuitable to write a browser in a GC-ed language. But for 99% of the code written everyday (including a PDF renderer), GC is a good enough solution to write memory-safe code.

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)

Browsers are probably the most exposed piece of software nowadays, and the vendors already do a lot of work to provide secure sandboxing. When using JavaScript, you're using a memory-safe language, in a sandboxed environment, which mean you need two exploits to get out of it (a bug in the js VM and a sandboxing bug). There's no guaranty that using another sandboxing system instead would offer better security, especially because you'll just have 1 layer of security.

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

If there's an easy way to give C or C++ code a acceptable level memory-safety, why aren't developers using it ? (Don't tell me people already do, because it would be the proof that those tools aren't able to reach the «acceptable level»). Notice that if such tool was invented tomorrow, it will also benefit browsers, and increase the security offered by JavaScript.

Re: Qubes Air: Generalizing the Qubes Architecture

#66

Post by ecesena »

kakarot wrote: post #62
ecesena wrote: post #45

Earlier quoted context omitted.

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop. All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing, and/or does an ico because I see a great incentive to run nodes of the cloud (because qubes utself provides all the building block for trust). > If you follow Qubes I…

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop. All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing That's strange, because the first sentence in your OP is: Qubes would make for a great startup and, given the time, prob a very successful ICO.

Ooops, you’re absolutely right and now I understand all the downvotes.

In my mind I was thinking to Qubes as the product(s), that could benefit from a startup. Similarly to as Kafka has Confluent, or Druid has Imply.

And I fully agree that Qubes the company should continue to be focus on research.

Re: Qubes Air: Generalizing the Qubes Architecture

#67

Post by kakarot »

ecesena wrote: post #66
kakarot wrote: post #62

Earlier quoted context omitted.

I don’t know how to write it better. I never said Qubes should change their biz model or do an ICO. Full stop. All I said is that their product would be great in the hands of a startup that focuses on a single hardware platform and does more marketing That's strange, because the first sentence in your OP is: Qubes would make for a great startup and, given the time, prob a very successful ICO.

Ooops, you’re absolutely right and now I understand all the downvotes. In my mind I was thinking to Qubes as the product(s), that could benefit from a startup. Similarly to as Kafka has Confluent, or Druid has Imply. And I fully agree that Qubes the company should continue to be focus on research.

FWIW, none of them came from me.

And I see the confusion now: Qubes isn't a company, the company is Invisible Things Lab.

Re: Qubes Air: Generalizing the Qubes Architecture

#68

Post by adultSwim »

xvilka wrote: post #8

Wonder about their progress of integration[1] with ReactOS. [1] https://github.com/QubesOS/qubes-issues/issues/2809

I think the Qubes team desperately needs more funding. Give them some of your money. Tell them your priorities.

Qubes + Whonix has been an enormously tremendous success.

I'm so happy to have Qubes as my daily driver at home. However, because of so little money coming in, development seems much more limited than it could otherwise be.

It's a wonder what they've been able to do so far with no budget and few external developers contributing.

Post reply on HN