Researcher Releases Hardened OS "Qubes"; Xen Hits 4.0 129
Trailrunner7 writes "Joanna Rutkowska, a security researcher known for her work on virtualization security and low-level rootkits, has released a new open-source operating system meant to provide isolation of the OS's components for better security. The OS, called Qubes, is based on Xen, X and Linux, and is in a basic, alpha stage right now. Qubes relies on virtualization to separate applications running on the OS and also places many of the system-level components in sandboxes to prevent them from affecting each other. 'Qubes lets the user define many security domains implemented as lightweight virtual machines (VMs), or 'AppVMs.' E.g. users can have 'personal,' 'work,' 'shopping,' 'bank,' and 'random' AppVMs and can use the applications from within those VMs just like if they were executing on the local machine, but at the same time they are well isolated from each other. Qubes supports secure copy-and-paste and file sharing between the AppVMs, of course.'"
Xen's also just reached 4.0; some details below.
Dominik Holling writes "With a small announcement on their mailing list, the open source community hypervisor Xen has reached the official release of version 4.0.0 today. The new features are: 'blktap2 (VHD support, snapshot discs, ...), Remus live checkpointing and fault tolerance, page sharing and page-to-disc for HVM guests, Transcendent memory (http://oss.oracle.com/projects/tmem/).' A complete list of all changes can be found on the Xen wiki and the source can be found on the official website and the Xen Mercurial repositories."
sounds promising (Score:1, Redundant)
I wonder how it will be when it hits stable, and what support it will have for devices
Re:sounds promising (Score:5, Funny)
Re: (Score:2)
dayofswords was talking about Qubes. Unfortunately timothy was a moron and posted together two different stories.
Re: (Score:1, Offtopic)
What a FLARE is for.... (Score:1)
That is actually a common misconception in the open source community. All dildos work well in an anus as well as they do in a vagina.
This is misleading. Ideally all butt tools have a FLARE (getting wider on the outside part). That's because objects are, ummmm, how do you say this, more likely to be sucked up and LOST back there.
That's the most important design difference with such equipment.
Stay safe and out of the emergency rooms, everyone!
Re: (Score:2)
I'm writing a driver for it to support the anal dildos i'm going to jam into your asshole.
What port does that plug into....?
OH wait, never mind.
Would you really need a driver for that? Wait, what kind of "driver" are we talking about here? Would a mallet work? Kinda gives "RAM-drive" a new meaning, eh?
(I better stop)
Virtualization doesn't work vs. file macrovirus (Score:4, Interesting)
Still, this is still a great advancement... will be interesting to see what performance impact this has.
Re: (Score:1, Interesting)
Sure, but nothing works against every threat. You will never discover a single perfect defense. It doesn't mean its useless to harden the single parts, like in this case OS components to keep rootkits away.
It's dead easy to make a rootkit for the existing operating systems. In Windows you need to hook the system API's. In Linux it's even easier - just replace the system executables. You even have a source code for them, making it really easy to add a simple code that checks if file/process/etc has certain t
Re: (Score:1)
Care to tell me why that doesn't work? It works for me. Sure you also need to hook some calls, but even that simple thing tricks most people, including good admins.
Re: (Score:2, Informative)
Its pretty easy to make a rootkit for any PC based OS ... the real problem is getting it loaded before the main OS. Contrary to popular belief, even with the advent of hardware virtualization helpers, boot viruses that hid themself away from the main OS are nothing new and have been around probably longer than you've owned your own computer.
The rootkit simply has to be first, after that theres nothing anyone can do.
Re: (Score:2)
In Linux it's even easier - just replace the system executables.
Wasn't there a best-practice that put /sbin, /bin, /usr, and all the other executable files on a separate partition that was mounted read-only? You pretty much left /home, /etc, and /var RW?
I guess if you wanted to install updates, you could remount RW or (safer) reboot into single-user mode, mount RW and install...
Re: (Score:2, Interesting)
I guess the idea is to run adobe PDF in it's own VM that has minimal permissions. Then when it is infected the virus can't access anything the VM isn't allowd to. (grsec let's you do something like that with the ACLs, roles and users.) For example if you do updates manually then you can restrict the VM of adobe Reader to not have net access. so the virus couldn't contact the outside world either. it's all a question of how much you're willing to compartmentalize your system. the more hassel you are willing
Re:Virtualization doesn't work vs. file macrovirus (Score:4, Informative)
I think the idea is that you'd run different domains to protect different sets of files. You'd run your tax software in a "tax" domain, and if any PDF software got infected, it wouldn't be able to touch the "tax" domain information.
Versus locked-down operating systems, you have a valid point (and my personal issue with this approach). However, it's not without its advantages. In a standard Linux system, every userspace process has access to around 330 system calls. Each one of these is an interface into the kernel, and a bug in even one of them is enough to take over the kernel. Furthermore, any application that can load kernel modules can potentially dominate the kernel.
In the Qubes system, each domain is protected by a virtualization layer. It does have domainhypervisor interfaces (similar to system calls) to allow I/O, graphics, and the copy-paste subsystem to run, but there are a lot fewer of them. They are oriented around a finite functionality - the aforemented I/O, graphics, etc., while system calls must exist for all userspace functionality. Therefore, as userspace applications get more complex and system calls (per-domain) increase in number and complexity, the domainhypervisor interface will be more or less static. This hopefully leads to them being easier to secure and lock down.
Re: (Score:2)
It does if you revert the VM after you are done. Nothing gets saved unless the infectious agent can break out of the VM. At worst, it'll send some spam if you allow the document reader VM net access.
Re:Virtualization doesn't work vs. file macrovirus (Score:4, Insightful)
A document that's infected would still need to be opened, and thus presents a vector that needs to be scanned against.
If the PDF viewer is running in a separate VM container, however, what exactly do you think it's going to accomplish? Read your other PDFs? sure. Delete them even? Okay. But since you probably did not give that VM access to your network it's unlikely to be able to do anything actually beneficial to a malware writer.
...still necessitating virus scanners (and app firewalls).
Well, virus scanners are a bonus, although not a lot of use on Linux given the amount of malware out there. Configuration of VMs takes over a lot of the same task as application level firewalls here, although the overhead tradeoffs of each approach should be looked at.
Re: (Score:1, Troll)
"If the PDF viewer is running in a separate VM container, however, what exactly do you think it's going to accomplish?"
Well, provided that "...Qubes supports secure copy-and-paste and file sharing between the AppVMs" I'll let it opened to your own imagination.
Re: (Score:2)
Well, provided that "...Qubes supports secure copy-and-paste and file sharing between the AppVMs" I'll let it opened to your own imagination.
One narrowly defined point of access to the other VMs is orders of magnitude easier to secure than the way it works now. It's the security equivalent of putting all your eggs in one basket and then watching that basket really, really closely.
Re: (Score:2)
I'd rather have my machine be a spambot for an hour than lose my PDFs.
Worst case scenario for being a spambot is that I get taken off the network for a few minutes. My PDFs? Maybe it's an archive of patents I need to review, the instructions for the fromulator, or my master's thesis. Certainly, they should all be backed up, and we should all test our *restore* from backup. That's the only real security, but I don't want deletion to happen lightly.
In general, do apps really need delete permission anyway
Re: (Score:2)
In general, do apps really need delete permission anyway? How about just giving them change permission. In other words, something like a local svn commit.
Agreed. And Qubes does provide the ability to revert an entire VM, so even if your PDFs were all deleted or corrupted, it should not be permanent if you catch it in time.
I think Macs come with something like that built in... the name escapes me.
Macs do have a nice, built in versioning called "Time Machine" but most users do not buy the required external drive to make use of it.
Re: (Score:2)
Why would you give a PDF reader the ability to modify or delete files on the disk? If you're running it in a virtual machine that's designed for security, I'd think that would be one of the things that would be prevented. Have it think of the disk as a really fast CD.
Re: (Score:2)
Why would you give a PDF reader the ability to modify or delete files on the disk? If you're running it in a virtual machine that's designed for security, I'd think that would be one of the things that would be prevented. Have it think of the disk as a really fast CD.
While I agree that seems a reasonable configuration provided it is easy for the user to get around (For PDF forms and PDFs I want to annotate), I don't think that is a normal setup for Qubes, the technology we're discussing. Rather, it lets you copy and paste files between VMs, so the workflow would probably look more like, downloading them in one VM, then copying them to your PDF reader's VM. Normal users would probably delete them from the former to save space. Now if your PDF reader reacted badly to a PD
Re: (Score:3, Insightful)
>Still, this is still a great advancement... will be interesting to see what performance impact this has.
Current machines (with the possible exception of so called "netbooks") are so insanely fast that the performance impact of a virtualised environment doesn't matter much save for a few very specific applications : games, graphic processing, etc. Not what typical users require. And there are ways to lower the impact when running a high requirement application. It will require a bit more RAM (if even that), but current machines are certainly adequate CPU-wise.
This is IMO one potential direction that OS archite
Re: (Score:2)
will be interesting to see what performance impact this has.
Performance impact?... performance improvement!
Now virus scanners can target specific scanning methods to specific VMs! Oh sure, there's some VM overhead - but think of the efficiency other software (like firewalls and virus scanners) gain by having everything segmented like this?
Hardware sandboxing (Score:3, Interesting)
Re: (Score:2)
I just hope they have working NUMA support and have jumbo frames fixed in the network bridging in Xen 4.0.
Re: (Score:2)
With the proliferation of multi-core CPUs and GPU clustering, I wonder how long until VMs simply become entirely separate physical systems sitting on your motherboard.
Yeah, I bet we could really accelerate the performance of these virtual systems if we could run them on dedicated hardware.
Re: (Score:3, Funny)
Then they'd just be M's... ;-)
Re: (Score:2)
Indeed. Circular logic is just surprising sometimes.
"Hey guys - wouldn't it be awesome if we setup the VM's so that each one of them had their own dedicated hardware!"
About as bright as the time one of our web guys decided to use DNS to assign all his servers a name based on their serial number - and then started asking if there was any way to assign a name to each one that was easier to remember.
Re: (Score:2)
"Hey guys - wouldn't it be awesome if we setup the VM's so that each one of them had their own dedicated hardware!"
A blade server can do that.
About as bright as the time one of our web guys decided to use DNS to assign all his servers a name based on their serial number - and then started asking if there was any way to assign a name to each one that was easier to remember.
I believe that's called a CNAME.
Re: (Score:2)
I believe this situation is what many slashdotters refer to as "woosh!"
Re: (Score:2, Funny)
Re: (Score:2)
Oh, and waaaaay before that, there were mainframes.
Sandboxes and Jails (Score:3, Interesting)
I'd like to read a serious comparison between this and jails in FreeBSD and sandboxes in Mac OS.
I think a lot of these ideas have been around for a very long time but they are such a pain in the ass, very few people actually use them.
Re: (Score:2)
Sounds very similar to the security level capabilities in OpenSolaris too.
Re: (Score:2)
Re: (Score:2)
I think a lot of these ideas have been around for a very long time
Ya think so? At least since 1972? And VM is still in active use and under development?
http://en.wikipedia.org/wiki/VM_(operating_system) [wikipedia.org]
Of course you have to violate 104 IBM patents to run it on an emulator, but still...
Unlike copyrights and trademarks, patents expire (Score:2)
At least since 1972? [...] Of course you have to violate 104 IBM patents to run it on an emulator
Unlike copyrights and trademarks, patents expire. So anything invented before 1990 is no longer patented. Or was this supposed to be a joke?
Re: (Score:2)
I think a lot of these ideas have been around for a very long time but they are such a pain in the ass, very few people actually use them.
I use FreeBSD jails all the time. Want a fresh, new environment for testing? ezjail-admin create testenvironment.example.com 10.20.1.5, ssh in, and start working on it. My understanding is that you're limited in practice to several tens of thousands of jails per machine, but I haven't bumped up against that yet.
Won't work (Score:1, Insightful)
This idea is an example of failing to understand the problem.
The problem with security comes from several primary sources:
1. Complexity. Too many layers with poorly understood security implications. This lady might actually understand the monster she spawned but no admin trying to implement it will understand all of the corner cases. See SELinux.
2. Shoddy coding. So this gets tossed over the wall and will (assuming it is to matter) be completed by people who don't really understand it. Unless this on
Re:Won't work (Score:5, Insightful)
1) Any system simple enough that anyone can use it, is either a toaster, or won't be useful in any customized way.
2) Coding doesn't need to be "shoddy" to be a security risk. It just simply needs to fail to realize the edge cases nobody thought of when writing the code. If you make the code complicated enough and run enough checks, it becomes complicated mess that nobody wants to use.
The problem with security is one of optimizing the risk to the amount of protections built into the system. Back in DOS days, I'm sure that DOS was insecure from many many levels, however because it was standalone, the security of "networking" wasn't even considered.
However the #1 security risk with computers isn't "code" or "Programs" or Hackers or whatever; the BIGGEST problem is Social Engineering, of which there is no fix other than "Stupid should hurt".
When a web dialog box can mimic a system dialog box saying "Your Computer is Infected CLICK HERE to fix it", which downloads and installs Antivirus 2010 crapware, the problem isn't Firefox, Windows or anything any programmer can fix. PEBAC, PICNIC and 1D10T errors aren't fixable by programmers.
And if you had to fix these problems you'd realize that Hackers and such are spending more time on social engineering attacks to get their viruses, trojans, and other malware onto computers than traditional methods.
Re: (Score:2)
> When a web dialog box can mimic a system dialog box saying "Your Computer is Infected CLICK HERE to fix it",
> which downloads and installs Antivirus 2010 crapware, the problem isn't Firefox, Windows or anything any
> programmer can fix. PEBAC, PICNIC and 1D10T errors aren't fixable by programmers.
Yes it is. Firefox should never set the executable bit on a download. (On Windows I guess it could neuter executables with an extra extension?) I don't care how 'convienient' it might be, just don't all
Re: (Score:2)
Second, a properly configured Linux machine isn't subject to that sort of attack because we use signed packages.
Oh really? From here [slashdot.org]:
Pwnie for Mass 0wnage
Awarded to the person who discovered the bug that resulted in the most widespread exploitation or affected the most users. Also known as ‘Pwnie for Breaking the Internet.’
Red Hat Networks Backdoored OpenSSH Packages (CVE-2008-3844)
Credit: unknown
Shortly after Black Hat and Defcon last year, Red Hat noticed that not only had someone backdoored the OpenSSH packages that some of their mirrors were distributing, but managed to sign the packages with Red Hat's own private key. Instead of revoking the key and releasing all new packages, they instead just updated the backdoored packages with clean copies, still signed by the same key, and released a shell script to scan for the MD5 checksums of the affected packages. What makes this eligible for the "mass0wnage" award is that nobody is quite sure how many systems were compromised or what other keys and packages the attackers were able to access. With very little public information available, the real casuality was the public's trust in the integrity of Red Hat's packages.
I suggest you make sure to read the bolded part a few times.
Re: (Score:2)
Oops the link got messed up. It's here [pwnie-awards.org].
Re: (Score:2)
You might want to read the details a bit more than the overly sensationalized version at pwnie-awards. None of the bogus packages have been seen in the wild. That incident was about as close of a near miss as you can get without a kaboom! but there was in fact no kaboom!. Will something like it happen eventually? Probably. Lt. Commander Susan Ivanova said it best, "Sooner or later, BOOM!" But it doesn't happen on a daily basis.
Re: (Score:2)
Second, a properly configured Linux machine isn't subject to that sort of attack because we use signed packages.
Signed by whom? Allow self-signed packages and malware authors can self-sign. Reject self-signed packages and you can't run anything that hasn't been packaged for your distro, such as new software written by a user of a different distro or proprietary commercial software.
Re: (Score:2)
None of those protections exist for Windows or Mac users which is why they can get 0wned with one bad click.
Not true. On Windows XP (for example), if you run as a limited user, nothing you run can take over the system, because you don't have privileges to do so.
Re: (Score:2)
Well, that's the point. If an app is sandboxed, it doesn't matter if that app is insecure... your OS won't get hosed by that app.
This is an implementation issue, not a theoretical issue. If the virtualized locations are tr
Re: (Score:2)
> Well, that's the point. If an app is sandboxed, it doesn't matter if that app is insecure... your OS won't get hosed by that app.
Except history tells us it never works that way in the real world. Java? Nope. BSD Jails? Nope. Virtualization? Nope. Containers? Nope. All promised to build a perfect isolated subsystem that apps couldn't escape from. All have had exploits. It helps, but it can also harm by leading to a false sense of security that causes people to do things they never would have
Re: (Score:2)
Hmmm... I wasn't aware that virtualization was a security failure, and that every instance of VM implementation failed to maintain security of the host OS. Do you know where I might get some good reading on the subject?
Re: (Score:2)
> Hmmm... I wasn't aware that virtualization was a security failure, and that every instance of VM implementation failed to maintain security of the host OS.
Google is yer friend. "security bug vmware" "security bug xen", etc. will quickly hit exploitable bugs that allow an attacker to escape. Meanwhile "security bug kvm" only gets crash bugs and potential escapes but then it is the new kid on the block. Not having any luck finding the bugs in the hardware, but pretty sure /. had something on it in the
Re: (Score:2)
Huh? I've heard of some corner case exploits on chroot'ed jails and the author of this system (Joanna) claimed some exploits on VM's which claim was controversial, IIRC. But in practice chrooted jails work pretty well and seem pretty secure if well implemented - I've been using them on FTP servers for years without incident, and they've passed numerous security reviews by our company's security team. VM's likewise seem to be pretty well isolated with either VMWare or Virtual Box. I'm not aware of any
Re: (Score:2)
Your post is an example of failing to understand information security.
Security practitioners have accepted the fact that it is infeasible to ever expect that all applications be free of security holes. It is also unwise to insist on the fantastically-higher expense of using dedicated hardware rather than virtualization for most applications. Because of this, we have adopted a strategy of "defense in depth" whereby we layer multiple countermeasures to reduce the probability of successful exploitation.
A secur
Re: (Score:2)
If history shows anything, giving an attacker any access to run code locally gives them all they need to leverage it into root eventually.
Perhaps, but this is another layer they'll have to get through before they can root the machine. So now they have to exploit the program, gain access to the VM that it's running on, and then jump from that VM to the host OS. It's not a perfect solution and it's almost certainly not impenetrable, but that doesn't keep it from being a useful tool.
Singularity (Score:3, Interesting)
Hardly a victory... (Score:5, Interesting)
Let me begin by saying that this sounds like a truly interesting approach to security. Virtualization technology defines very clear hardware-enforced boundaries between software domains. In the standard case, those domains contain different operating systems, each of which are provided privilege level-based sub-domains. In this particular case, each domain is dedicated to running sets of user-space applications, and the hardware boundary is used for userspace isolation, as opposed to virtual machine OS isolation.
So my "home" domain is infected, but my intellectual property is in my "work" domain. The virtualization boundary means that a virus can get Ring 0 access and still not be able to touch those IP files. Hurray ... except wait. There must be an interface between the "home" domain and the hypervisor, else things like copy-and-paste and hardware resource arbitration can't work. Here's what some infection paths would look like:
Maybe the paths can be locked down better, but a vulnerability is a vulnerability. It's clearly harder for a virus to get full control, but that's just throwing another obstacle in the way. If one is bad, and two is better, maybe three is even better, but nothing's perfect. Why is the domain-to-hypervisor path considered any more secure than the userspace-to-kernel path? If it's not, you're just adding more complexity, which could mean more potential for vulnerabilities! If you're locking down privilege boundaries, kernels like FreeBSD (jails) and even userspace execution environments like Java (JVM) have been working on that for years.
It's cool, but I doubt it will be game-changing.
Re: (Score:2)
Why is the domain-to-hypervisor path considered any more secure than the userspace-to-kernel path? If it's not, you're just adding more complexity, which could mean more potential for vulnerabilities!
It's considered more secure in the same way that it's more secure to have a firewall instead of just trying to secure the applications. As long as they can secure the interfaces between the host OS and the VMs, they have security. If they don't secure that interface, then they're left with no more vulnerabilities than they had before.
Re: (Score:1, Insightful)
The hypervisor is simpler and therefore easier to audit for issues (or even prove correct).
With KVM in the kernel (Score:2)
Since KVM is in the mainline and redhat is now supporting that 100% this seems like a bad time to start anything on Xen.
To which I say good riddance, virtualization is just another app and kvm gets this right.
Re: (Score:2)
You may not like Xen as an OS, but it does have some very nice qualities that are hard to deliver on Linux alone.
Re: (Score:2)
Suse will also support KVM in SLES11 SP1 and expects [slideshare.net] that long term it will "become equivalent to Xen". Ubuntu and Fedora also support KVM. Xen doesn't care about what distros do (they don't care about getting all their code merged in mainline either), they seem to think that they can ignore what mainstream OSes do, just like VMWare. I suppose they will die some day, I'm not using third party software if I can get the same funcionality with the OS.
Re: (Score:2)
Xen kernel developers have been busy re-writing and cleaning up the the dom0 support using the pvops framework. That work is now getting final/ready, and the Xen pvops dom0 patches will be sent to upstream Linux shortly.
About bloody time too! :)
Just looking at http://wiki.xensource.com/xenwiki/XenDom0Kernels [xensource.com] shows what a mess Xen Dom0 is and how hard it is to get working.
Re: (Score:2)
(Mod parents up, particularly the informative anonymous grandparent!)
This is a major milestone for Xen parent (heh) machines because we now have a very clear prospect of a stable Xen dom0 kernel branching process, creating code that has a reasonable amount of support by both the Xen kernel developers and mainline kernel developers - the divergence is getting smaller practically by the month.
The dom0 kernel list shows what the past divergence at 2.6.18 has created - a flurry of interconnected yet differe
Re: (Score:2)
It's good to see this but it might be too late. Redhat is dropping Xen dom0 support in RHEL6 in favour of KVM. Probably because there is no Xen release based on the kernel versions (2.6.31 and 2.6.33) in the Fedora versions that it'll likely be based off.
Maintaining the 2.6.33 with bug and feature backports for 7 years from RHEl6's release is going to be work enough for them, let alone trying to keep up an old 2.6.18 Xen kernel.
For desktop distros it's even worse. While it's fine when running RHEL5 on a ser
Re: (Score:2)
They explain that in their FAQ and architecture PDF. One of the reason is that KVM doesn't allow the moving of (eg) networking and I/O drivers into separate unprivileged guests.
Remus (Score:3, Informative)
The Remus stuff in Xen is very cool. A couple of days ago there were some posts about HP's NonStop stuff as an example of something you could do with Itanium but not with commodity x86 crap. Remus means that you can. It builds on top of the live migration in Xen to keep two virtual machines exactly in sync.
Computers are deterministic, so in theory you ought to be able to just start two VMs at the same time, give them the same input, and then see no difference between their state later on. It turns out that there are a few issues with this. The most obvious is ensuring that they really do get the same input. This means that they must handle the same interrupts, get the same packets from the network, and so on. Anything that is used as a source of entropy (e.g. the CPU's time stamp counter, jitter on interrupts, and so on) must be mirrored between the two VMs exactly. This was already possible with Marathon Technology's proprietary hypervisor on x86, but is now possible with Xen.
As with the live migration, you can kill one of the VMs (and the physical machine it's running on) and not even drop network connections. This leads to some very shiny demos.
Oh, and I should probably end this post with a gratuitous plug for my Xen internals book [amazon.co.uk]
Re: (Score:1)
This was already possible with Marathon Technology's proprietary hypervisor on x86, but is now possible with Xen.
It was also possible with VMware's FT technology and I bet it's significantly easier to configure than whatever just got hacked into Xen.
Maybe there are advantages to Xen's approach? Maybe it supports vSMP? I would have been more interested in hearing about that, than a plug for your book.
Re: (Score:2)
It's pretty easy to configure Remus. You just run a couple of commands to turn it on, although you need some other stuff (as you do with live migration) to make sure both VMs on different machines get the same network packets. Remus hasn't 'just got hacked in' to Xen. The first prototype was demonstrated at the XenSummit back in Spring 2007. It's had three years of testing and refactoring before being shipped as an official part of the hypervisor (it's been publicly available as a third-party patch set
Functionality-based Application Confinement (Score:1)
Re: (Score:2)
Systems such as SELinux and AppArmor allow precise policies to define the types of actions and resources which are made available to each application. However, the finer the granularity of privilege assigned, the more detailed and complex policies become.
I don't see how this is really a problem though, particularly with Apparmor. When you want to create a profile, you just start the app in profile mode, run it through its usual paces then hit save. The profile runs automatically when apparmor is restarted. That seems like an almost point and shoot level of ease to enabling very robust security that anybody that's comfortable with the command line can do. Suse even has a GUI for it. With Ubuntu, a simple apt-get install apparmor-profiles installs ready
Re: (Score:1)
Re: (Score:2)
Disappointed (Score:2)
Saw Qube.
Thought Cobalt.
Leaving sad.
Xen and EC2 (Score:2)
I've had a lot of problems with EC2 that upgrading to at least 3.3 would
fix. I just hope Amazon would start thinking about upgrading EC2 or migrate
it from Xen as they seem to have gotten stuck with 3.1 and I've seen
nothing that indicates there's going to be an upgrade.
Re: (Score:2)
Interesting but the problem is the end user. (Score:3, Insightful)
Re: (Score:2)
But his banking Qube should be setup not to allow executaion of any software(Except the banking software). And if it's using a webbrowser it should be setup only to access the banks website.
But I still think that having banks give our/sell special purpose computers with a rom chip as only storage is the best way to prevent hacking of bank accounts.
All money transfer operations should then be send to this computer, where the user would then have to confirm the data on the special purpose computer, which coul
Re: (Score:2)
You mean a "Trusted Computing" device? Yes, and maybe we should call congress and ask them to try passing the SSSCA [cryptome.org]again so Palladium will be required by law. Then Microsoft can rule us all!
Re: (Score:1)
that is an oversimplification, yeah end user is a big point but Joanna has been using this aproach for a while, it might be a little paranoic, but that girl knows a LOT about security, and we will be following her advices for a few year i'm sure
Old news (Score:2)
Oh good, more useless abstraction ... (Score:1)
Great ... another 'OS' that has its own new set of problems ... plus before its actually useful in the real world you'll have to come up with ways to give it all the speed power and flexibility of the OSes we use now, which it doesn't have ... by the time you add it back you'll end up right back where you are now.
Apps and data is useless on an island. When you're on an island you're safe from attackers.
To actually do something useful however, data needs to move on and off the island, at which point, you're
Re: (Score:2)
What this virtualization will do, if it works, is prevent applications from making any unauthorized changes to the OS. On my box at home, if I run a program, I'm taking the chance that it can't get root access somehow and mess with my system files. If it's running in a virtual machine, and can't get out of it, it can trash the virtual machine all it likes and I'll just release the VM when I've run the program and spin up a new one to run the next program.
It isn't perfect, of course, even if it can prev
IBM's MVS followed these same ideas (Score:2)
I guess they don't watch the Mythbusters (Score:1)
From the article:
"These mechanisms finally move the bull (untrusted data) from the china shop (your data) to the outside where it belongs (a sandbox)."
The Mythbusters showed that bulls will try to miss china if it's at all possible. http://mythbustersresults.com/episode85
I gonna make a new OS based on Qubes (Score:1)
Dirty bedsheets please! (Score:2)
I'll just wait for (Score:1)
GNU HURD [wikipedia.org], thank you very much.
It's just around the corner.
Click the link and...? (Score:2)
Being able to create AppVMs on the fly is a great idea, and one that should be a common OS feature. But it sounds like it will have the same problem that a site-specific browser does: how do you ensure that a given operation will be carried out in the proper domain?
For instance, you get an email from a colleague (in your email security domain) that includes a link. You click the link. Now, in which domain does the browser window open?
If you tell me I need to copy the link, switch to my random-crap-from-coll