Attempts to solve security problems [with] dualism are usually wrong.
June 2, 2015 8:43 AM Subscribe
Joanna Rutkowska is the creator of the Qubes OS, one of the preeminent security researchers on virtualization security, and CEO and founder of Invisible Things Lab.
The Qubes OS relies on what has been described as a Bento security model, breaking components up into similar trust domains to reduce the impact of a compromise of any individual component. The OS also features disposable virtual machines for those moments when you aren't sure if something is safe or not.
Partially inspired by this post on women in OSS.
The Qubes OS relies on what has been described as a Bento security model, breaking components up into similar trust domains to reduce the impact of a compromise of any individual component. The OS also features disposable virtual machines for those moments when you aren't sure if something is safe or not.
Partially inspired by this post on women in OSS.
I think Joanna is pretty badass, and Qubes is a good thing. However, my understanding of Qubes (and similar solutions) is that they push the application separation (which has traditionally been enforced by the OS) down to the hardware by making extensive use of the virtualization extensions that exist on modern processors. Basically, it seems that Qubes aims to transition an OS that runs many processes (with the OS doing the process segmentation) to many OS's each running a few processes (with the hardware doing the OS segmentation).
I think practically speaking this will have a net positive effect because Intel/AMD have better QA than most software shops, however OS's are, comparatively speaking, easy to audit. The lack of widespread, easy introspection into the hardware troubles me. Admittedly we have that problem in our current implementation, we're just depending on it for less now.
posted by yeahwhatever at 10:10 AM on June 2, 2015 [1 favorite]
I think practically speaking this will have a net positive effect because Intel/AMD have better QA than most software shops, however OS's are, comparatively speaking, easy to audit. The lack of widespread, easy introspection into the hardware troubles me. Admittedly we have that problem in our current implementation, we're just depending on it for less now.
posted by yeahwhatever at 10:10 AM on June 2, 2015 [1 favorite]
How are we depending on the hardware for less now than we would be with more virtualization? We're 100 percent dependent on the hardware no matter what. If you can't trust the MMU, you can't trust the OS, even without virtualization. I'm also not sure how you'd ever introspect hardware that didn't "want" to be introspected.
If I had a wish, it'd be for Intel and whoever to simplify the hardware and stop trying to "solve" every security problem by adding yet another more privileged mode that the previous modes can't see. But virtualization doesn't seem to be a big example of that; it's not a lot of complexity and it gets you a real benefit.
I think what virtualization is doing right now is providing a way to dig ourselves out of a hole. OSes were built for many years without adequate internal compartmentation. Applications became dependent on being able to touch everything in the machine, so it became hard to add compartmentation without rewriting all that code. With virtualization (and an excess of capacity thanks to Moore's law), you have another crack at putting multiple applications on the same hardware while protecting them from one another... you can run what seem like several whole systems at once. It's complicated, but at least it's a path forward.
There are, of course, signs that that may get screwed up (not through any fault of Joanna or Qubes; she's one of the good guys). People want to be able to communicate between the VMs better, and they want to get some of those resources back by reducing duplication. Done incorrectly, that could enable those VMs to reach inside one another more than they should, and put us right back in the same hole. But, conversely, there's hope that the VMs could end up being lighter and being able to communicate better while maintaining a sane compartmentation model. They already see themselves as parts of a network, and that could start to look like, say, a capability system if you squinted hard enough.
I like the ideas behind Qubes, and I've read Joanna's stuff and it's clear she knows what she's doing. Maybe this'll be my occasion to finally try that install image I have lying around.
posted by Hizonner at 10:24 AM on June 2, 2015 [3 favorites]
If I had a wish, it'd be for Intel and whoever to simplify the hardware and stop trying to "solve" every security problem by adding yet another more privileged mode that the previous modes can't see. But virtualization doesn't seem to be a big example of that; it's not a lot of complexity and it gets you a real benefit.
I think what virtualization is doing right now is providing a way to dig ourselves out of a hole. OSes were built for many years without adequate internal compartmentation. Applications became dependent on being able to touch everything in the machine, so it became hard to add compartmentation without rewriting all that code. With virtualization (and an excess of capacity thanks to Moore's law), you have another crack at putting multiple applications on the same hardware while protecting them from one another... you can run what seem like several whole systems at once. It's complicated, but at least it's a path forward.
There are, of course, signs that that may get screwed up (not through any fault of Joanna or Qubes; she's one of the good guys). People want to be able to communicate between the VMs better, and they want to get some of those resources back by reducing duplication. Done incorrectly, that could enable those VMs to reach inside one another more than they should, and put us right back in the same hole. But, conversely, there's hope that the VMs could end up being lighter and being able to communicate better while maintaining a sane compartmentation model. They already see themselves as parts of a network, and that could start to look like, say, a capability system if you squinted hard enough.
I like the ideas behind Qubes, and I've read Joanna's stuff and it's clear she knows what she's doing. Maybe this'll be my occasion to finally try that install image I have lying around.
posted by Hizonner at 10:24 AM on June 2, 2015 [3 favorites]
What distinguishes this from a bunch of VMs will be the interoperation model, but I agree with all that's been said in principle: better to start with some approximation of the ideal of full isolation and then provide explicit blueprinted interfaces between than to start with a big bucket of processes and try to wedge boundaries between them. It's a promising approach.
Naturally one would like to see task-optimized kernels -- obviously modularity helps here -- to help control the costs of memory overhead and startup time, and a way of collapsing out redundant code pages and static memory; KSM is designed to do that dynamically, but that's wasteful and complex in a system like this where each kernel is part of a known runtime configuration.
posted by George_Spiggott at 11:12 AM on June 2, 2015
Naturally one would like to see task-optimized kernels -- obviously modularity helps here -- to help control the costs of memory overhead and startup time, and a way of collapsing out redundant code pages and static memory; KSM is designed to do that dynamically, but that's wasteful and complex in a system like this where each kernel is part of a known runtime configuration.
posted by George_Spiggott at 11:12 AM on June 2, 2015
(I have never heard if her or her work before, but I find it enormously interesting. Thank you for the post, bfranklin!)
posted by wenestvedt at 12:59 PM on June 2, 2015
posted by wenestvedt at 12:59 PM on June 2, 2015
How are depending on it less now? Right now the logic for segmentation/IPC is implemented in the OS, and the hardware has relatively simple tasks relating to the MMU for process separation (and filesystem etc etc). If we ask the hardware to do more complex things, we depend on it's behavior/correctness more.
Obviously if the hardware is bugged it doesn't matter what sits on top of it, was not suggesting otherwise.
Basically what I was trying to say is we have to have the segmentation/IPC logic somewhere. Right now it is of lower quality, in software, but with good introspection. Qubes shifts to higher quality, in hardware, with poor introspection. This is probably a net win, but it's a decision we should make recognizing the trade offs.
posted by yeahwhatever at 1:25 PM on June 2, 2015
Obviously if the hardware is bugged it doesn't matter what sits on top of it, was not suggesting otherwise.
Basically what I was trying to say is we have to have the segmentation/IPC logic somewhere. Right now it is of lower quality, in software, but with good introspection. Qubes shifts to higher quality, in hardware, with poor introspection. This is probably a net win, but it's a decision we should make recognizing the trade offs.
posted by yeahwhatever at 1:25 PM on June 2, 2015
Honestly, something like this has to be the future, because the flawed idea that some security researchers have that all code must be audited everywhere is not scalable.
posted by smidgen at 2:02 PM on June 2, 2015
posted by smidgen at 2:02 PM on June 2, 2015
Qubes is nice, but it doesn't fix crummy code, not even crummy application code. You need more than that.
I tend to take the view that what's flawed is the idea that you will or should always be able to keep "scaling". People keep making things more and more brittle, and more and more interlinked, and more and more of a monoculture, and more and more other people are taking more and more of an interest in attacking that stuff in better and better ways. Eventually it's going to fail spectacularly. It's already starting, actually.
I don't know exactly what happens after there are a few really big events. Maybe customers stop buying your software if you can't show why they should trust it. That's already happening in some areas, although the buyers right now are really unclear on what they need to demand. Maybe it becomes illegal to distribute code, or to expose it to the Net, if it's not created by certified people following specific standards... just as it's illegal to build skyscrapers that way.
But something is going to happen. I don't think that it's going to be acceptable 20 years from now for just any bozo to hang out a shingle and start shoveling features as fast as they can type. If that slows things down, that's OK; we have more than enough shiny apps. It'll be less fun, though, and that's truly a shame.
Auditing is not a primary method for developing secure code, by the way. In a properly functioning process, it's a relatively small part of the answer. As presently used, it's a band-aid.
posted by Hizonner at 4:58 PM on June 2, 2015
I tend to take the view that what's flawed is the idea that you will or should always be able to keep "scaling". People keep making things more and more brittle, and more and more interlinked, and more and more of a monoculture, and more and more other people are taking more and more of an interest in attacking that stuff in better and better ways. Eventually it's going to fail spectacularly. It's already starting, actually.
I don't know exactly what happens after there are a few really big events. Maybe customers stop buying your software if you can't show why they should trust it. That's already happening in some areas, although the buyers right now are really unclear on what they need to demand. Maybe it becomes illegal to distribute code, or to expose it to the Net, if it's not created by certified people following specific standards... just as it's illegal to build skyscrapers that way.
But something is going to happen. I don't think that it's going to be acceptable 20 years from now for just any bozo to hang out a shingle and start shoveling features as fast as they can type. If that slows things down, that's OK; we have more than enough shiny apps. It'll be less fun, though, and that's truly a shame.
Auditing is not a primary method for developing secure code, by the way. In a properly functioning process, it's a relatively small part of the answer. As presently used, it's a band-aid.
posted by Hizonner at 4:58 PM on June 2, 2015
Maybe it becomes illegal to distribute code, or to expose it to the Net, if it's not created by certified people following specific standards... just as it's illegal to build skyscrapers that way.
It's also illegal to build a shed in your backyard without getting proper permits. Which seems a little silly to me but not completely unreasonable.
But what's the software equivalent of that? Writing a bunch of shell scripts to wget to some public API? At what point do those shell scripts turn into an application that needs oversight by a certified person?
The best thing about computers is that they are so easy to program. It's the whole point. I don't think any solution that demands you get a license before you can write a freeware game, or share an Excel spreadsheet that contacts a server somewhere, is going to work.
I personally think that we as a society are just going to have to accept that computers are not secure, and create a legal, regulatory, and insurance framework for managing the risk. Part of that is going to be improving technology, part of it is going to be setting things up so that the consequences of a data breach are not so severe for "civilians" (i.e. make it harder to actually commit identity theft once you get some information). But mainly it's just accepting that there are bad actors, and just like car theft and robbery, we're not capable of preventing it all.
posted by vogon_poet at 8:21 PM on June 2, 2015 [1 favorite]
It's also illegal to build a shed in your backyard without getting proper permits. Which seems a little silly to me but not completely unreasonable.
But what's the software equivalent of that? Writing a bunch of shell scripts to wget to some public API? At what point do those shell scripts turn into an application that needs oversight by a certified person?
The best thing about computers is that they are so easy to program. It's the whole point. I don't think any solution that demands you get a license before you can write a freeware game, or share an Excel spreadsheet that contacts a server somewhere, is going to work.
I personally think that we as a society are just going to have to accept that computers are not secure, and create a legal, regulatory, and insurance framework for managing the risk. Part of that is going to be improving technology, part of it is going to be setting things up so that the consequences of a data breach are not so severe for "civilians" (i.e. make it harder to actually commit identity theft once you get some information). But mainly it's just accepting that there are bad actors, and just like car theft and robbery, we're not capable of preventing it all.
posted by vogon_poet at 8:21 PM on June 2, 2015 [1 favorite]
Qubes is a step (a very good step) in the direction of capability based security... in which you explicitly supply access tokens (aka capabilities) to applications when you run them, and the default otherwise is no access to anything.
Capability based security is the exact opposite of how most things work now, where an application can do anything it wants.
posted by MikeWarot at 9:29 PM on June 2, 2015
Capability based security is the exact opposite of how most things work now, where an application can do anything it wants.
posted by MikeWarot at 9:29 PM on June 2, 2015
I'm trying to think how this helps mom and pop end users. I think most of those interactions are cloud based at this point. They go to the credit card sites through a web browser, banking through the same web browser, get mail through gmail, bills through the company websites, etc.
This doesn't stop someone from compromising the vm running their browser and then capturing their data.
The attack surface for home users is going to be browser/internet based. I'm not sure this addresses that.
On the corporate side of the equation, it may help companies reduce their attack surface. Email client application can be seperated from browser application and so on. IANA security consultant, but that seems like the smaller slice of the secuirty nightmare pie though. And coporate IT security at most shops has evolved far beyond the days of clicking on an attachment in Outlook, no?
posted by herda05 at 10:10 PM on June 2, 2015
This doesn't stop someone from compromising the vm running their browser and then capturing their data.
The attack surface for home users is going to be browser/internet based. I'm not sure this addresses that.
On the corporate side of the equation, it may help companies reduce their attack surface. Email client application can be seperated from browser application and so on. IANA security consultant, but that seems like the smaller slice of the secuirty nightmare pie though. And coporate IT security at most shops has evolved far beyond the days of clicking on an attachment in Outlook, no?
posted by herda05 at 10:10 PM on June 2, 2015
Qubes is nice, but it doesn't fix crummy code, not even crummy application code.
I think she's operating from the perspective that she will have a reasonably secure PC in spite of the crappy code that's out there because 1) she can't fix it all on her own, and 2) the fact remains that a lot of people need that crappy code to get work done.
posted by prepmonkey at 12:57 PM on June 3, 2015
I think she's operating from the perspective that she will have a reasonably secure PC in spite of the crappy code that's out there because 1) she can't fix it all on her own, and 2) the fact remains that a lot of people need that crappy code to get work done.
posted by prepmonkey at 12:57 PM on June 3, 2015
however OS's are, comparatively speaking, easy to audit.
This isn't even wrong. I say that as someone who started his career at a company that wrote hight-security, high-trust operating systems.
posted by kjs3 at 6:51 PM on June 3, 2015
This isn't even wrong. I say that as someone who started his career at a company that wrote hight-security, high-trust operating systems.
posted by kjs3 at 6:51 PM on June 3, 2015
« Older The Russian Troll Factory | Good Grief! Newer »
This thread has been archived and is closed to new comments
posted by KaizenSoze at 10:10 AM on June 2, 2015 [1 favorite]