Qubes Air: Generalizing the Qubes Architecture
qubes-os.org
qubes-os.org
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.
Got it.
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.
pdf.js exists!
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.
All Im saying on this since you seem set on Javascript for efficient, secure apps. We arent going to agree on that premise.
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.
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.
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?
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.
The idea of having an "operating system" made up of components dispersed across the globe seems like a fantasy that is too good to be true.
If Qubes can finally provide a method for passing through NVIDIA GPUs with this kind of architecture, Xen or not, that would be incredible. It's the only reason I had to leave Qubes.
I found a good introduction to Plan 9 architecture in this comment:
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.
I mean I get cloud computing and such, but this seems to be aimed as a consumer OS, which is very sensitive to delays and whatnot.
The "real problem" exposed by Meltdown and Spectre is running untrusted software on the same hardware where sensitive information resides. Moving away from physical coupling defends against potential sidechannel attacks.
The Qubes approach of "careful decomposition of various workflows, devices, apps across securely compartmentalized containers" seems to point a way forward after this sobering assessment:
http://robert.ocallahan.org/2018/01/long-term-consequences-o...
Well obviously. Which is why people try to avoid that as much as they can when they are handling actually sensitive information.
> Moving away from physical coupling defends against potential sidechannel attacks.
... is a correct deduction, but using cloud VMs hardly qualifies as following the principle (except if they are only used for lowest-privilege stuff, but even then, the system now requires connectivity). Now you don't know who else is on your hardware, and you don't even control the hardware in the first place.
Read up on Amoeba and Sprite in the 80's.
It's good of them to admit that the layers-upon-layers approach just doesn't bring in any additional security if you have buggy/unsecure hardware.
As long as we're in Intel x86 land, the Plan 9 service-per-box approach is probably about the best we can do, and I'm not saying that with any joy, or as an endorsement.
Or, perhaps we can claw our way back to the 1960s and reclaim working memory protection? As obvious as that sounds, I wouldn't take it for granted. People already accept all sorts of half-broken proprietary bullshit for GPU performance, bootloading, AMT, etc. From the mailing lists, looks like Intel is trying to normalize that for CPUs as well.
I was positively and at the same time negatively surprised reading about the 30k users. All issues/obstacles reported don’t seem so unachievable if one can imagine to focus on one specific hardware platform and with a good marketing team. I understand this is beyond a research project, but it would make for a great startup.
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 on the ICO scene isn't a very positive one, and I don't think she wants to complicate her company by pivoting to a blockchain model that has absolutely no relevance to developing secure operating sytems.
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 do, since 2010, when I was doing very similar research on trusted cloud computing.
> If they can find a home in the enterprise market I wish it to them, but this doesn’t mean someone else can try a more aggressive consumer route, or an alternative for their cloud model.
I respect a ton their work, and as I said in my very first comment I think they should focus on the research part, and someone else could provide capital and grow the consumer product.
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.
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.
And I see the confusion now: Qubes isn't a company, the company is Invisible Things Lab.
Of course they'd also have to pick their launch during a bull market, because nobody cares about ICOs in a bear market. If there's one innovation the "blockchain" has brought, is extreme liquidity and high funding potential for any type of startup, including open source projects that wouldn't even be considered by VCs ever, or they'd have to beg for individual donations otherwise.
The blockchain is a P2P Silicon Valley (you heard it hear first).
And don't list "extreme liquidity" as a reason.
Edit: OK, I take it back. Replacing VMs with discrete devices on local networks is very cool. I just wish that they'd emphasized that, and then talked about using cloud resources. Indeed, what boggled my mind is that someone would go through the hassle of learning Qubes, and then put some of it in the cloud.
Cloud is just a way to distribute computation, and make sure storage is always available to you. Everything should be assumed to be protected — I mean, they protect video memory among processes/apps, you’d bet they protect your data on the cloud.
Rather, it sounds like they are trying to properly abstract the isolation technology away from any specific implementation. They then realized that this would also allow "Qubes on the Cloud" with relatively little extra effort.
From a personal choice standpoint, it seems we will still have the option of avoiding cloud zones completely if we so desire, so no harm there.
If we think about the sociology of security however, lowering the barrier to entry seems like an overall win, assuming we believe in the Qubes security model.
It's a lot like fingerprint readers on phones. Sure, they're not near as strong as a high entropy password, but they're convenient enough so people who previously never locked their phones now use a fingerprint lock.