Introducing Qubes 1.0 ("a stable and reasonably secure desktop OS")(theinvisiblethings.blogspot.com.br)
theinvisiblethings.blogspot.com.br
Introducing Qubes 1.0 ("a stable and reasonably secure desktop OS")
http://theinvisiblethings.blogspot.com.br/2012/09/introducing-qubes-10.html
9 comments
Brief description from their web site: "Qubes is an open source operating system designed to provide strong security for desktop computing. Qubes is based on Xen, X Window System, and Linux, and can run most Linux applications and utilize most of the Linux drivers. In the future it might also run Windows apps." (http://qubes-os.org/Home.html)
In fact, the version in development already runs Windows. The blog has a screenshot showing Windows running in 'desktop mode' (as in, you currently don't have single application windows for the Windows VM).
The extra requirements for this seem to be (ignoring that this isn't yet released) that you're having vt-x support, for all I remember.
The extra requirements for this seem to be (ignoring that this isn't yet released) that you're having vt-x support, for all I remember.
Previously:
http://news.ycombinator.com/item?id=1246990
http://news.ycombinator.com/item?id=2645170
This story won't see much traction on HN. The cult of Mac is too strong, and HN users generally aren't interested in secure operating systems.
http://news.ycombinator.com/item?id=1246990
http://news.ycombinator.com/item?id=2645170
This story won't see much traction on HN. The cult of Mac is too strong, and HN users generally aren't interested in secure operating systems.
Actually folks on HN are interested in secure operating systems but they recognize that creating such is a Hard Problem (tm) which someone who is an unknown [1] in the field is unlikely to have achieved.
Now you can read up on Mark Miller's published papers [2] on Joule (actually pretty secure) and some of the issues associated with making things secure and get a much better feeling of solidity (for example).
So when the press release comes out that its passed the Defense department's B1/B2 review, then I suspect it will get a lot of interest here and else where.
[1] http://www.linkedin.com/profile/view?id=10279027 LinkedIn profile, one job CEO of this thing? A blog full of black hat sort of exploits but I didn't see any peer reviewed work.
[2] http://research.google.com/pubs/author35958.html
[3] http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluat...
Now you can read up on Mark Miller's published papers [2] on Joule (actually pretty secure) and some of the issues associated with making things secure and get a much better feeling of solidity (for example).
So when the press release comes out that its passed the Defense department's B1/B2 review, then I suspect it will get a lot of interest here and else where.
[1] http://www.linkedin.com/profile/view?id=10279027 LinkedIn profile, one job CEO of this thing? A blog full of black hat sort of exploits but I didn't see any peer reviewed work.
[2] http://research.google.com/pubs/author35958.html
[3] http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluat...
Joanna Rutkowska is famous in computer security circles and highly credible on this particular topic.
The "black hat sorts of exploits" attributed to her tend to be things like, "abusing odd, barely-documented corners of x86 chipsets to bypass hardware-encrypted trusted boot roots". Thinking less of a professional in my field for having exploits attributed to them tends to be a bad idea, but it's a uniquely bad idea in Rutkowska's case.
Outside of conference presentations, Rutkowska doesn't have much peer-reviewed work in the literature. That's because Rutkowska is originally from the malware/rootkit/virus part of the industry. For obvious reasons, antivirus doesn't generate a lot of peer-reviewed academic research. One of those obvious reasons is that they're too busy printing money hats to bother. (This to my chagrin; I am very much not from the AV/malware part of the field).
I'm not vouching for Qubes or even saying that I think the approach (of semi-transparently allocating secure VMs for each application or trust domain on the system) is viable. But Rutkowska is worth taking seriously.
The "black hat sorts of exploits" attributed to her tend to be things like, "abusing odd, barely-documented corners of x86 chipsets to bypass hardware-encrypted trusted boot roots". Thinking less of a professional in my field for having exploits attributed to them tends to be a bad idea, but it's a uniquely bad idea in Rutkowska's case.
Outside of conference presentations, Rutkowska doesn't have much peer-reviewed work in the literature. That's because Rutkowska is originally from the malware/rootkit/virus part of the industry. For obvious reasons, antivirus doesn't generate a lot of peer-reviewed academic research. One of those obvious reasons is that they're too busy printing money hats to bother. (This to my chagrin; I am very much not from the AV/malware part of the field).
I'm not vouching for Qubes or even saying that I think the approach (of semi-transparently allocating secure VMs for each application or trust domain on the system) is viable. But Rutkowska is worth taking seriously.
> Outside of conference presentations, ...
Almost on topic: I have to say the team is also really cool and approachable at conferences - and for that I'm very grateful as a member of the unexperienced audience. They can really adjust the explanations to the right level for the general crowd, which must be quite hard considering the topic.
Almost on topic: I have to say the team is also really cool and approachable at conferences - and for that I'm very grateful as a member of the unexperienced audience. They can really adjust the explanations to the right level for the general crowd, which must be quite hard considering the topic.
Generally security people are fairly approachable. If you're at BlackHat, all you have to do is say "I saw your presentation -- neat work, but I have some questions" or "want to grab a beer?" and you'll most likely have a good conversation.
Thank you for the background. Perhaps this time it is posted it will get a bit more traction/pageviews. My history was from early in the Java group trying to do security work in what was clearly going to be targeted as an exploit vector. For a variety of reasons that work didn't get out into Java 1.0 but pieces of it made it out into the crypto API and elsewhere. Folks with solutions to the 'trusted computing' problem that were both simple and wrong were a dime a dozen.
The meta issue here is that clearly the black hat work has some 'trade secret'ness too it in terms of competitors but it cries out for being published/peer reviewed post-money making opportunity or something.
The meta issue here is that clearly the black hat work has some 'trade secret'ness too it in terms of competitors but it cries out for being published/peer reviewed post-money making opportunity or something.
Invisible Things is pretty well respected in the trusted computing space (at least among the hacker world, not the DoD certification world)
SKPP pretty much sucked off all the "paper-writing industry" folks a few years ago into a kind of boring niche. Mark Miller is a big exception to that, but it's not a really vibrant research area compared to other parts of security now.
SKPP pretty much sucked off all the "paper-writing industry" folks a few years ago into a kind of boring niche. Mark Miller is a big exception to that, but it's not a really vibrant research area compared to other parts of security now.
Unknown? Rutkowska has done some of the most interesting security research in virtualization security, including most famously the "Blue Pill" and "Red Pill" demonstrations - escalating privileges to Dom0 (and detection of presence of a hypervisor by the client). For both HVM and PV architectures (e.g., Windows & Xen), she and her colleagues have done ground-breaking work that have impacted the implementation of every major commercial and open source virtualization.
Academic pubs != Relevance
Edit: But since you asserted it, here are researchers that cite her work (over 130, including IEEE and ACM folk):
http://scholar.google.com/scholar?cites=13610021170603453007...
Academic pubs != Relevance
Edit: But since you asserted it, here are researchers that cite her work (over 130, including IEEE and ACM folk):
http://scholar.google.com/scholar?cites=13610021170603453007...
Just to throw in another data point; I have never worked on or in secure Operating Systems and have no particular interest in them. I recognise the name Joanna Rutkowska and I am aware that she is well-known and respected in this field. In my case at least, she's well-known enough that people outside the field have heard of her.
[deleted]
Yes, Apple is the reason most people don't care about an unbelievably inconvenient desktop sandbox.
Haha. :)
To be fair, Apple's focus on usability and convenience could be linked to Qubes, in that they represent very different points on the "How much users should be thinking about security" spectrum.
To be fair, Apple's focus on usability and convenience could be linked to Qubes, in that they represent very different points on the "How much users should be thinking about security" spectrum.
Qubes to me seems like what I imagine would happen if DARPA threw a roomful of security nerds together in the 90's and told them to come up with something to let intelligence analysts process mixed-class data. The software equivalent of a one-way-transfer device.
It makes me long for the day that current pc's end up relegated to the attic of computing.
It makes me long for the day that current pc's end up relegated to the attic of computing.
Oh no, not at all, Qubes is a much lighter weight alternative to what the roomful of security people DARPA did throw together in the 90s to try and design those systems.
They're throwing another roomful of people together to build something similar right now. If Joanna wants and maneuvers right, her lab could end up getting a lot of the contracts to do a lot of things the DoD wants done.
I'm not sure whether she's interested in that though, or whether she's pursued it already. They'd probably ask for a bunch of stuff that would involve headaches. Either that or she's already doing work on it. Dunno, to be honest.
They're throwing another roomful of people together to build something similar right now. If Joanna wants and maneuvers right, her lab could end up getting a lot of the contracts to do a lot of things the DoD wants done.
I'm not sure whether she's interested in that though, or whether she's pursued it already. They'd probably ask for a bunch of stuff that would involve headaches. Either that or she's already doing work on it. Dunno, to be honest.
I cannot for the life of me see what Qubes has to do with Apple.
Thanks for linking to the previous discussions. It would have ben better if you hadn't tried to derail this discussion with the prediction of how the post would fare and "cult of mac" comment.
Not exactly a security guy (I'm actually a mathematician/statistician not exactly a computer engineer) how do these compare in security terms to sandboxing applications or using lxc from the linux kernel?
As far as I remember you could use different kernels for Xen VMs and the physical hardware, then the only way to compromise the system would be if I could escalate privileges on the hypervisor, right?
As far as I remember you could use different kernels for Xen VMs and the physical hardware, then the only way to compromise the system would be if I could escalate privileges on the hypervisor, right?
Right, but the point of this (I think) is to be able to be a "compartment mode workstation" -- a single X server which runs x clients themselves executing in multiple Xen VMs, with guarantees about isolation and how the windows are managed.
There's a continuum of security and usability between having (a) N machines in N rooms for N tasks to having (b) 1 machine on a single desk running N tasks. You can have a KVM switch and multiple computers sharing a keyboard/mouse/monitor, which gives you a high degree of isolation (very close to (a)), or you can have compartment mode, where windows themselves have security labels, but then you need an advanced system to protect apps in one window from other windows, including window masquerading attacks. If you do it well, it's ideally close to (a) as well.
The problem with virtualization on a desktop is that certain resources (video/keyboard drivers) don't like to be virtualized, so you end up running them in the system host area. Applications also tend to want pretty low-level access to those resources. It used to be the performance overhead of all of this was very high, but now it's not as big a deal (at least for normal 2d type apps).
The last good Compartment Mode Workstation I remember was Trusted A/UX (built on apple's first UNIX operating system) from the early 1990s. It wasn't particularly good.
There's a continuum of security and usability between having (a) N machines in N rooms for N tasks to having (b) 1 machine on a single desk running N tasks. You can have a KVM switch and multiple computers sharing a keyboard/mouse/monitor, which gives you a high degree of isolation (very close to (a)), or you can have compartment mode, where windows themselves have security labels, but then you need an advanced system to protect apps in one window from other windows, including window masquerading attacks. If you do it well, it's ideally close to (a) as well.
The problem with virtualization on a desktop is that certain resources (video/keyboard drivers) don't like to be virtualized, so you end up running them in the system host area. Applications also tend to want pretty low-level access to those resources. It used to be the performance overhead of all of this was very high, but now it's not as big a deal (at least for normal 2d type apps).
The last good Compartment Mode Workstation I remember was Trusted A/UX (built on apple's first UNIX operating system) from the early 1990s. It wasn't particularly good.
I genuinely can't think of anything else I'd rather use less than this.
I think MAC (Mandatory Access Control) applied to a desktop environment, picking a better language than C and actually thinking about stuff is more than sufficient to get around the existing problems...
Virtualization is just another pile of complexity and performance problems to deal with. It's not a magic bullet. Consider the following as well:
http://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-vi...
I really don't want this solution.
I think MAC (Mandatory Access Control) applied to a desktop environment, picking a better language than C and actually thinking about stuff is more than sufficient to get around the existing problems...
Virtualization is just another pile of complexity and performance problems to deal with. It's not a magic bullet. Consider the following as well:
http://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-vi...
I really don't want this solution.
I really like the idea and I just can't wait for it to be more prevalent on mobile devices.
I'm sick of the lack of control over my data I have on android (not to mention iOS).
I'm sick of the lack of control over my data I have on android (not to mention iOS).
This is not a flame or a troll, but seriously try Windows Phone. It actually gets this spot on.
Can you say anything more about this or provide a link? I'm not familiar with this aspect of Windows Phone.
Every interaction that it makes to the network is controllable via user preferences and is documented. It does not send data unless you allow it to. Each application is fully isolated from others so applications cannot read from each other by design as well.
Nice video here: http://www.youtube.com/watch?v=pzviQLCPCG4
An application can read the unique ID of the device (which is used for session persistence between service calls) but not access any other information unless allowed to.
Effectively there is no way for it to steal all the data in that list unless you physically tell it that it's ok to do it.
It's the mobile platform that scares the shit out of me the least. They did good here.
Nice video here: http://www.youtube.com/watch?v=pzviQLCPCG4
An application can read the unique ID of the device (which is used for session persistence between service calls) but not access any other information unless allowed to.
Effectively there is no way for it to steal all the data in that list unless you physically tell it that it's ok to do it.
It's the mobile platform that scares the shit out of me the least. They did good here.
Thanks. That video seems to only show settings/confirmation-prompts for the usage of location data, but if you can control whether individual apps have access to the network, too, that's handy.
I will reserve judgement until I've given it a try. It might not be the ideal solution, but it looks like a nice stop-gap solution.
It doesn't seem to support using full disk encryption during installation. I like the way it sandboxes things, but I'm not giving up full disk encryption for it.
Look again.
LUKS is used for all filesystems. Qubes was specifically engineered to block the Evil Maid scenario and similar vectors for notebooks. See pg. 31 from http://qubes-os.org/files/doc/arch-spec-0.3.pdf:
"There are several things that all together make the storage secure in the Qubes architecture:
1. Confidentiality, understood as preventing one VM from reading other VMs data
2. Confidentiality, understood as preventing access to the data when the machine is left unattended (full disk encryption, resistance to Evil Maid attacks, etc)
3. Integrity, understood as preventing one VM from interfering with the filesystem used by other VMs
4. Security non-critical role: a potential compromise of the storage subsystem doesnʼt result in other system components, like other VMs, compromise. Storage subsystem is not part of the TCB in Qubes OS."
See also, Section 7.1 System Boot Process, and 8.5 Resistance to Physical Attacks (or just search for "disk encryption").
LUKS is used for all filesystems. Qubes was specifically engineered to block the Evil Maid scenario and similar vectors for notebooks. See pg. 31 from http://qubes-os.org/files/doc/arch-spec-0.3.pdf:
"There are several things that all together make the storage secure in the Qubes architecture:
1. Confidentiality, understood as preventing one VM from reading other VMs data
2. Confidentiality, understood as preventing access to the data when the machine is left unattended (full disk encryption, resistance to Evil Maid attacks, etc)
3. Integrity, understood as preventing one VM from interfering with the filesystem used by other VMs
4. Security non-critical role: a potential compromise of the storage subsystem doesnʼt result in other system components, like other VMs, compromise. Storage subsystem is not part of the TCB in Qubes OS."
See also, Section 7.1 System Boot Process, and 8.5 Resistance to Physical Attacks (or just search for "disk encryption").
Strange. I went through the install process in a VM and quit out when it started writing a filesystem without making any mention of disk encryption.
I left a comment on the blog about this 7 hours ago. Seems it hasn't been approved but other comments have. Strange.
Very cool! So how does this compare to Chrome OS and it's sandbox technique for tabs. Yes I know it is only a browser, but with offline apps, executable code (native client), and local APIs, it is more like a normal OS.
I've been following this, even tried to buy hardware to support it. Fair warning though, Version 1.0 does not support Ivy Bridge architecture. There's an unsupported experimental branch that is supposed to work, though.
>So, we believe Qubes OS represents a reasonably secure OS.
>(...) But then again, I'm biased, of course ;)
At least, they are honest heh
>(...) But then again, I'm biased, of course ;)
At least, they are honest heh
Wow, talk about being out of touch with the real world. Developers, especially Linux developers, really need to give up on this whole "Desktop" operating system idea. It's not going to work. It is already dead. And I can hardly believe we are still using these ancient systems for many tasks even today. There is no future in WIMP, and people really need to stop developing these Windows clones already. It was lame 10 years ago. If you are still working on desktop OS clones today, you so are terribly out of touch with the real world there really is no hope for you or your product. Get over it.
Touch-based (and by extension, NUI-based) OS'es and mobile applications are the future. Windows always sucked. Mac OS always sucked. Every desktop OS ever built sucked because it is a horrible way to use a computer. Nobody ever really wanted to use these terrible desktop metaphor systems... they only ever did because they had to.
Touch-based (and by extension, NUI-based) OS'es and mobile applications are the future. Windows always sucked. Mac OS always sucked. Every desktop OS ever built sucked because it is a horrible way to use a computer. Nobody ever really wanted to use these terrible desktop metaphor systems... they only ever did because they had to.
I'm sorry but none of that is even vaguely true, as true or false as something can be when it is entirely opinion.
Touch screens are to desktops as push bikes are to tractors. You need both. Some people even use both. Or just one. Or neither.
Maybe you feel this way because you've been driving a tractor around all this time and you feel like you've been wasting your time, however some of us (I imagine a lot of us on HN) like to do farming occasionally :-)
Touch screens are to desktops as push bikes are to tractors. You need both. Some people even use both. Or just one. Or neither.
Maybe you feel this way because you've been driving a tractor around all this time and you feel like you've been wasting your time, however some of us (I imagine a lot of us on HN) like to do farming occasionally :-)
[deleted]
That reminds me of the John Ford quote:
"If I had asked people what they wanted, they would have said faster horses."
That's a great quote, and it is definitely true that often times users don't know what they want until they've been shown it.
However, we still use horses as transport. Sure, it's often just for pleasure, but the Police still use them, and rural people still use them, or people in mountains etc, because in those situations they are still better than anything Ford came up with.
So I don't think that quote is relevant here. People have accepted 'post-pcs' into their lives and they are good at lots of things. There are things that larger 'real' computers are better at though, and I don't see any evidence that will change.
However, we still use horses as transport. Sure, it's often just for pleasure, but the Police still use them, and rural people still use them, or people in mountains etc, because in those situations they are still better than anything Ford came up with.
So I don't think that quote is relevant here. People have accepted 'post-pcs' into their lives and they are good at lots of things. There are things that larger 'real' computers are better at though, and I don't see any evidence that will change.
Henry Ford. And he appears to have never actually said it. And this attitude cost Ford the early lead in market share.
http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fa...
http://blogs.hbr.org/cs/2011/08/henry_ford_never_said_the_fa...
The funny thing is that I parsed the quote verbatim on the first pass and it made me think the quote was referring to westerns -- John Ford being the famous movie actor.
Took my old brain a second or two to realize that I had previously heard that quote associated with Henry Ford.
Took my old brain a second or two to realize that I had previously heard that quote associated with Henry Ford.
Okay so I mistakenly wrote his first name... I don't see how that invalidates what I've said.
What's there to "invalidate"? You just made an assertion, not an argument.
You say that nobody wants to use desktops and people want computers to disappear. Unlike you, I don't believe that already, so do you have some evidence for it?
You say that nobody wants to use desktops and people want computers to disappear. Unlike you, I don't believe that already, so do you have some evidence for it?
The blogpost I linked pointed out that this quote is often used not to justify a particular idea or position but instead to justify not paying attention to your audience. Paying attention doesn't mean groveling or completely giving up all of your own control.
If you ask people what they want now, they will say touch screens. That doesn't mean it's the future.
that was actually Samuel Ford
I think you're missing the context here. This system is not about UI. It's not about desktop experience either. It's about making sure your email client is so separated from your $BUSINESS_APPLICATION, that exploiting one does not allow you to access anything on the other - and doing that without relying on handcrafted libvirt configs and hopefully without much processing overhead.
I guess the desktop environment was just a random choice of "this works, so just leave it in" from whatever distribution they started with.
I guess the desktop environment was just a random choice of "this works, so just leave it in" from whatever distribution they started with.
This is what AppArmor and SELinux are for.
In many cases yes, but there are additional issues Qubes is taking care of. For example AppArmor could only restrict your access to Xorg completely - but once you have access, you can read anything from the screen.
That already exists: it's called a web browser.
Granted, browsers aren't without their security holes, but then again, neither are operating systems. Given the amount of effort being put into browsers to make them secure (especially Chrome), my money's on that.
Granted, browsers aren't without their security holes, but then again, neither are operating systems. Given the amount of effort being put into browsers to make them secure (especially Chrome), my money's on that.
That's exactly why this system goes further. In a browser, it's usually enough to exploit the browser's chrome to get to other sites. Or exploit the browser's binary to get to other apps.
This system goes at least 2 layers deeper. System itself makes sure that each window has its own desktop environment and can't see others. Hardware takes care about the separation between security containers the apps are running in. Protection of the app itself is just the first line of defence and is not going away, so whatever sandboxing exists in the browser still applies.
They are also talking about protecting hardware sharing from being used to cross boundaries which is another layer of paranoia (not unwarranted)
This system goes at least 2 layers deeper. System itself makes sure that each window has its own desktop environment and can't see others. Hardware takes care about the separation between security containers the apps are running in. Protection of the app itself is just the first line of defence and is not going away, so whatever sandboxing exists in the browser still applies.
They are also talking about protecting hardware sharing from being used to cross boundaries which is another layer of paranoia (not unwarranted)
Websites aren't sufficiently sandboxed from each other though. Otherwise we wouldn't have CSRF, XSS and Click Jacking attacks.
If you build a webmail client, you need to know all about these attack vectors, and you need to go out of your way to prevent your application from being susceptible to them. Websites are insecure by default.
I don't trust a web browser with my email at all. Not yet. If I were to use webmail, I'd make sure to set up a separate instance of Firefox to run it in, with it's own profile. I will continue to use Thunderbird for now though.
I'm not against the idea of using webmail, I just don't think the web is secure enough yet.
If you build a webmail client, you need to know all about these attack vectors, and you need to go out of your way to prevent your application from being susceptible to them. Websites are insecure by default.
I don't trust a web browser with my email at all. Not yet. If I were to use webmail, I'd make sure to set up a separate instance of Firefox to run it in, with it's own profile. I will continue to use Thunderbird for now though.
I'm not against the idea of using webmail, I just don't think the web is secure enough yet.
I'm going to go ahead and guess that the people behind Qubes were worrying less about the fact that the desktop paradigm may be fundamentally flawed in terms of usability (not going to argue on that one), but more about security, which is the stated goal of the project. Desktops may be on the way out, but that doesn't mean that we can't do some very basic security work on the heart of the OS. Looking at some of the documentation, it appears that their VM-per-application-group idea could scale very well to touch- and app-based interfaces with some work.
Security has a vital place in every OS, regardless of the skin you put over the top of it.
Security has a vital place in every OS, regardless of the skin you put over the top of it.
You made a lot of assertions there, but in my opinion, there's nothing like a desktop computer for day-to-day use. The future may be in touch-based applications, but if it is, it's going to tough to get anything accomplished in it. Maybe I'm just clinging to my guns and desktop computer, but I don't think I'm alone in that.
The reason i don't think this is funny is because it's compromising the maturity of this community. Please create a new thread stating your grievances, instead of distracting things.
So please explain to me: what the hell does the input method (keyboard, mouse, touchscreen) have to do with the low-level security properties of a system? If anything, the switch to tablets and thus more ubiquitous computing makes security an extremely critical issue (see the many discussions about permission systems, application sandboxes, malware leaking personal information etc...). It will become even more pressing in the future, if you think about devices that are controlled by thought (EEG etc...).
Think of a java applet in a browser catching all your keyboard input for instance; the general idea is that secure system must guarantee that user input goes where intended and only there.
Sure. Of course. But my point is, how is that different for touch screen-based input or a real keyboard? The grandparent poster seems to think that in the post-pc era, security problems disappear in puffs of colored icons and magical gestures.
That is seriously retarded. You don't use your computer to do actual work, do you? Because the keyboard simply is the best way to do things that are not downloading porn and browsing Facebook.