| |||||||||||||
Qubes beta 1 releasedQubes beta 1 releasedPosted Apr 13, 2011 20:50 UTC (Wed) by epa (subscriber, #39769)In reply to: Qubes beta 1 released by alvieboy Parent article: Qubes beta 1 released Yes, applications run in isolated context - in a virtual machine, in fact. What we're seeing is that the interface provided to the virtual machine - Unix system calls - has failed to provide the isolation wanted. It's too complex and too leaky, and although processes cannot access another process's memory, they can by default do all sorts of other things like open TCP socket connections. Instead the standard application interface is becoming a generic x86 architecture with a network interface. Applications are increasingly packaged to run against that API - as whole operating system images. Communication between applications happens using TCP/IP only and not via a shared filesystem or other IPC mechanisms. It's sad in a way. It would be better if operating system process isolation worked better out of the box - so that even if your Firefox is totally 0wned the rest of your files are safe, for example. But rather than waiting for that to happen it is more convenient for users to give up and run things in full virtualized hardware.
(Log in to post comments)
Qubes beta 1 released Posted Apr 13, 2011 21:31 UTC (Wed) by pboddie (subscriber, #50784) [Link]
Wouldn't "subusers" or "hierarchical users" - stuff like pboddie.firefox being the "user" that runs Firefox - be a reasonable Unixy solution, though? In my experience of sandboxing discussions around programming languages, things quite often boil down to "we're doing this for the Windows people because, of course, you'd just run it as a different user on Unix", together with an acknowledgement that you could still be a nuisance on the network.
Qubes beta 1 released Posted Apr 13, 2011 23:26 UTC (Wed) by skissane (subscriber, #38675) [Link]
I think Andy Valencia's VSTa operating system had a similar concept. Rather than a flat UID namespace (as POSIX provides), one can have a multi-level hierarchial namespace... 37.1.9...
I guess how it worked (never played with VSTa, so maybe I'm misunderstanding it) is that if I am a process of UID 37, I can fork a process with UID 37.x, e.g. 37.1. As UID 37 I have full owner access to all 37.1's objects and all 37.2's objects, but 37.1 doesn't have owner access to 37.2's objects or plain 37's objects.
So yeah, if I am user skissane, I could create 'subusers' like skissane.firefox, skissane.firefox.tab1, skissane.firefox.tab1.pdfreader...
Qubes beta 1 released Posted Apr 13, 2011 23:29 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
with namespaces, this is a concept that applies to linux as well
Qubes beta 1 released Posted Apr 14, 2011 1:29 UTC (Thu) by skissane (subscriber, #38675) [Link]
UID namespaces in Linux are only a single-level hierarchy right? namespace.uid. My understanding was that VSTa provided a hierarchy of arbitrary depth. Also, you need special privilege to create a new namespace right? I thought the idea with VSTa, was that any process can create a sub-uid under its current uid, no special privilege required...
Qubes beta 1 released Posted Apr 14, 2011 16:56 UTC (Thu) by elanthis (guest, #6227) [Link]
SELinux roles provide something similar, as well. Unfortunately, only if using SELinux.
I'd really, really, really like to see the core roles stuff enter the mainstream POSIX/Linux interface. Not the full domain management stuff of SELinux, but just enough to control file access and do PID checks to see which process are running in which roles (while still allowing them to belong to a specific user).
You can _almost_ emulate roles using groups, newgrp, group passwords, and so on, except that a process can drop its groups.
Qubes beta 1 released Posted Apr 13, 2011 22:07 UTC (Wed) by zlynx (subscriber, #2285) [Link]
Amen!
That's what I've been saying about this virtualization for security craze.
Existing operating systems already provide virtual environments to applications. There's no need for another one, just properly use what is already there! For example: run Firefox as a separate user account or use SELinux to isolate it.
I've also been saying that as more features are added to virtual machine environments, our systems are going to end up with the very same problems we already have. The VMware, qemu or VirtualBox virtual devices, networking and fancy control ports are going to have bugs. These bugs will end up being exploited and then you're right back in the same security situation that exists already.
Qubes beta 1 released Posted Apr 13, 2011 23:34 UTC (Wed) by aliguori (subscriber, #30636) [Link]
It all boils down to monolithic kernels vs. microkernels. Everyone knows microkernels are going to take over the world because they are super secure and have tiny interfaces to userspace.
Clearly, this monolithic kernel design Linux uses is a passing fad and we'll all start using HURD once it's ready.
Qubes beta 1 released Posted Apr 15, 2011 1:11 UTC (Fri) by csigler (subscriber, #1224) [Link]
Your first paragraph made me furrow my brow in doubt. Your second one made me laugh out loud! Well done, sir. Touche'
Clemmitt
Qubes beta 1 released Posted Apr 13, 2011 23:39 UTC (Wed) by aliguori (subscriber, #30636) [Link]
QEMU is just a userspace process. It doesn't short cut any of the Linux protection mechanisms.
That's the nice thing about QEMU/KVM, it's not reinventing a new security architecture. It just leverages what Linux already does.
Qubes beta 1 released Posted Apr 13, 2011 23:50 UTC (Wed) by dlang (✭ supporter ✭, #313) [Link]
that's true until you start implementing special hooks to improve performance by punching through the abstraction layers.
Qubes beta 1 released Posted Apr 13, 2011 23:54 UTC (Wed) by robert_s (subscriber, #42402) [Link]
"That's what I've been saying about this virtualization for security craze."
Well where have you all been hiding? I've been feeling like the only one.
"I've also been saying that as more features are added to virtual machine environments, our systems are going to end up with the very same problems we already have."
Exactly: the chief reason these "appliances" have been fine is because they have been disparate services which typically don't need to communicate. As people start to require these appliances to communicate, we're going to find developers having to break holes in the walls and the same problems appearing.
I find the funniest thing to be all these companies who are switching their infrastructure to VMware are effectively switching themselves back to a proprietary platform.
Or maybe the funniest thing is that the fashionable interchangeable interface for running self contained applications in 2011 involves emulation of an Intel 8259.
Qubes beta 1 released Posted Apr 14, 2011 0:24 UTC (Thu) by jarrett.miller (guest, #60765) [Link]
I am sorry but you guys don't get it. Its not virtualization that is attractive it is Intel TXT. But TXT requires virtualization to do its thing.
The point of TXT is to allow you to create a measured (aka hashed via TPM) hypervisor that can protect itself even from the OS that launches it. But the main thing is it moves the root of trust. Under old style Trusted Computing (TC) you had to trust the BIOS of the your computer and no one in their right mind should trust that thing. But with TXT all you have to trust is Intel as the new root of trust is not your BIOS but is instead the AC module that Intel publishes over at the tboot project.
The point is that you can't build a trusted software stack using a classic operating system model without rewriting everything from scratch. But with TXT you can create a means to migrate slowly over time to a trusted and verified software stack.
So this whole "Security through Virtualization" is not about the isolation that it provides but about providing a migration path to a system where you can actually tell what software is running on your system.
I recommend you read the origional post about Qubes to understand the motivation and maybe pick up a copy of "Dynamics of a Trusted Platform" published by Intel Press.
Qubes beta 1 released Posted Apr 14, 2011 7:15 UTC (Thu) by cmccabe (guest, #60281) [Link]
Let's say that I'm Random Q. Blackhat. I compromise your system, get root, and install a malicious firmware upgrade on your ethernet device. Something really nasty that sends a copy of every packet you send to blackhat.example.com.
How is TXT going to stop me? The ethernet device is part of the "web of trust," right? You have to trust it.
Another example. FooCorp makes wireless chipsets and wireless drivers. Their wireless driver has a buffer overflow which can be exploited by a certain packet sent by the access point. How is TXT going to stop MyBlackHatAccessPoint from rooting all the passers-by with that chipset?
Qubes beta 1 released Posted Apr 14, 2011 10:41 UTC (Thu) by jarrett.miller (guest, #60765) [Link]
I think you have a fundamental misunderstanding about what TXT and/or trusted computing are for. They are not technologies that prevent compromise. There main point of their existence is for you to be able to get a a verifiable list of software on your machine. Nothing more and nothing less. IOW the main point is so that you can reliably tell when you have been rooted not to prevent being rooted.
Now for specific examples. In a TXT enabled hypervisor the ethernet device is not part of the tree of trust. That is the point behind TXT. In classical Trusted Computing (TC) it would have been but TXT was created so that a hypervisor does not have to trust the: BIOS, system firmware, or OS that launched it.
Now for your wireless driver buffer overflow example. In a TXT style system there is going to be a hypervisor and it protects itself from all of the OS's that it is in control of via hardware protections (basically IOMMU with page protection lists). Some OS partition will be where that wireless driver exists. So when someone exploits that flaw and roots that OS partition then the hypervisor should be able to tell (new executable pages come in to existence or the contents of executable pages change). So it has done its job and let you know that said partition is rooted.
I will repeat this to make it crystal clear. TXT is not a mechanism to protect you from software faults. Its just the most basic mechanism to allow you to reliably know what software is running on your machine. You still have to build the rest of your security stack on top of that. Its just trying to lay a sound foundation on which to build better security, It in and of itself is not some silver bullet.
Qubes beta 1 released Posted Apr 14, 2011 21:07 UTC (Thu) by job (guest, #670) [Link]
Is it common to seek hardware assistance for keeping track of which software you run? I can understand it if you have a locked down environment with whitelisted software, but not for servers.
That trusted software of yours might have holes in it. And when an attacker successfully tricks that software into running his code, it'll be just as trusted as anything else. Just witness all those game consoles out there, they have a lot more elaborate protection than TXT but every single one has been hacked to run unsigned ("homebrew") code.
Qubes beta 1 released Posted Apr 14, 2011 22:02 UTC (Thu) by cmccabe (guest, #60281) [Link]
Please don't interpret me as "attacking" TXT. I'm just trying to get a sense of what it is and is not.
The truth about the PC platform is that there are a lot of gaping holes in the security model at the hardware level. For example, the PCI bus allows PCI devices to do arbitrary DMA transfers to and from system memory. ACPI bytecode is loaded into the kernel and executed at ring level 0. If TXT allows Intel to work around some of these problems, then it will be a good thing.
However, you can never really completely get away from the need to trust your hardware vendor. That is what I was getting at with the first example, and I think you missed it. Once the data leaves the motherboard and flows to, for example, a separate ethernet card, that card can do whatever it wants. TXT may be able to protect my system memory, but it can't prevent the firmware in my ethernet card from doing something unexpected.
Countries buying military hardware are increasingly concerned about the possibility of "kill switches" being embedded in it. Trusting Intel, an American company, probably isn't something that they're that excited about. Intel, like every other company, has had exploitable bugs in their software in the past. I remember Joanna Rutkowska pointing out an exploitable flaw in an SMM. It would also be relatively easy for them to embed a backdoor into TXT or into the processor itself if they really wanted to.
Of course this whole discussion ignores the many exploitable flaws in the software stack. Until those are fixed, many organizations will quite reasonably regard spending money on implementing TXT as closing a mouse hole, while leaving the barn door open. Chinese hackers only needed to exploit a few vulnerabilities in Adobe (PDF) Reader to steal the secrets of dozens of Fortune 500 companies.
Long story short, TXT is an interesting technology, but it does not allow you to "reliably know what software is running on your machine." That is something that you probably can never do. You can only get closer and closer to certainty, but never reach it.
Qubes beta 1 released Posted Apr 15, 2011 12:49 UTC (Fri) by jarrett.miller (guest, #60765) [Link]
I am afraid you are just plan wrong on that last statement. Please go read the docs.
As long as you believe that Intel correctly implemented the hardware and correctly implemented the AC module (and here I define correct to mean it implements the semantics of the GETSEC[SENTER] instruction without error) then TXT does indeed allow you to know what is running on your computer reliably.
Heck even classical Trusted Computing lets you do that the problem with the old style of it was that you didn't have to just trust Intel to get the hardware and the AC module right you had to trust the BIOS and all the firmware were not doing anything shady (A bad assumption).
Qubes beta 1 released Posted Apr 16, 2011 21:29 UTC (Sat) by cmccabe (guest, #60281) [Link]
> As long as you believe that Intel correctly implemented the hardware and
> correctly implemented the AC module (and here I define correct to mean it > implements the semantics of the GETSEC[SENTER] instruction without error) > then TXT does indeed allow you to know what is running on your computer > reliably.
Even if I believe that-- and I already discussed some reasons why I shouldn't-- exploit in another layer of the stack will allow an attacker to run something different on my computer. And even if I magically was able to audit all of that software, it still wouldn't tell me anything about what software is running on, for example, my RAID card, or inside my computer mouse.
You can get closer and closer to certainty, but never reach it.
Qubes beta 1 released Posted Apr 20, 2011 18:29 UTC (Wed) by PaXTeam (subscriber, #24616) [Link]
> [...] then TXT does indeed allow you to know what is running on your computer reliably.
not exactly. it tells you what was running at the time SENTER executed, it says nothing about the future. in a post somewhere above you tried to dismiss the problem of exploitable bugs by saying this:
> Some OS partition will be where that wireless driver exists. So when
so this hypervisor wouldn't let guest kernels modify themselves (think of the alternatives mechanism in linux) or load kernel modules? can you name a single widespread (or heck, any) distro which would be able to run on this hypervisor? so you can't do this. but then runtime code generation must be allowed for the guest kernels and that means any kernel exploit is back in business, TXT/hypervisor/etc didn't improve anything, you still don't know what code runs on your box.
Qubes beta 1 released Posted Apr 15, 2011 1:01 UTC (Fri) by njs (guest, #40338) [Link]
> a hypervisor does not have to trust the: BIOS, system firmware, or OS that launched it.
I think you need to elaborate on what you mean by "trust" here -- it's a notoriously polysemous word. Certainly if some program's correctness depends on its ability to send packets, then it has to trust the ethernet driver to actually do that. Of course, right now the ethernet driver can also go ahead and read any random piece of host memory that it wants to via DMA -- fixing that would certainly improve things.
> In a TXT style system there is going to be a hypervisor and it protects itself from all of the OS's that it is in control of via hardware protections (basically IOMMU with page protection lists).
Not a critical point, but this is exactly how the kernel works now.
> So when someone exploits that flaw and roots that OS partition then the hypervisor should be able to tell (new executable pages come in to existence or the contents of executable pages change).
We already have NX protection, which does essentially the same thing -- prevents buggy programs from creating new executable code. It helps, but it's by no means a guarantee. There are the clever tricks for accomplishing exploits without generating executable code (return-to-libc and all that), and if you can exploit an environment that contains a JIT or dynamic language runtime then you can perform arbitrary actions without triggering the protections.
So I don't really see how TXT makes that much of a difference.
Qubes beta 1 released Posted Apr 15, 2011 13:00 UTC (Fri) by jarrett.miller (guest, #60765) [Link]
1. Trust in the context of that sentence can be defined as trusting the BIOS, firmware, or spawning OS to not disable (either remove it or prevent it from being scheduled or receiving interrupts that it requires) as well as not tamper with (read,write or over write memory owned by the hypervisor).
2. Why are you brining correctness in to this. I never said that TXT had anything to do with correctness. So don't conflate the argument. All I said is that it allows you to get a reliable list of whats running on your computer.
3. On IOMMU. Are you sure you are correct? Last time I went over the kernel source (maybe 12 months ago) the kernel did not use IOMMU to prevent a DMA device from overwriting portions of kernel memory.
4. As it pertains to your last paragraph. TXT makes a big difference when you are talking about kernel level or firmware root kits and not application level exploits.
Qubes beta 1 released Posted Apr 14, 2011 10:25 UTC (Thu) by PaXTeam (subscriber, #24616) [Link]
> But TXT requires virtualization to do its thing.
where did you read that? 315168.pdf says this:
> Intel TXT can be used to launch any type of code. However, this section
Qubes beta 1 released Posted Apr 14, 2011 10:51 UTC (Thu) by jarrett.miller (guest, #60765) [Link]
Excuse me for not being supper precise. I should have said the most common use case for TXT requires virtualization.
You are correct. Any conforming code that is able to be launched in a measured launch environment can run in TXT context. However I have yet to see a good example of when this is useful outside of virtualization. Mainly because setting up a TXT context is so expensive. After all its basically a platform reset so you have to stop all CPU's and flush all caches.
I have seen people try to do this but it just seems to have little merit in my opinion. For example Dr. Mike Reiter of UNC Chapel Hill tried to do just that for password encryption. Basically launching a TXT application for every key press (google him for the papers). But the costs seems way to high to me.
Cheers
|
|||||||||||||