Bromium twists chip virty circuits to secure PCs and servers Bromium, the security startup launched a year ago by the techies behind the open source Xen server virtualization hypervisor, are lifting the veil a bit on the software that they are cooking up, while at the same time announcing a big new bag of cash to pay for the ongoing development of what the company is calling a microvisor …
They aren't actually solving the real problem which is trust. We trusted Microsoft that machines running windows were secure and that turned out to be a mistake. Now the fix is that we're supposed to trust these guys that whatever software they create will make our machines secure. Unless they can mathematically prove this then all they've done is add another layer of complexity for malware authors to exploit.
I wouldn't say it's trust... Nothing can be truly trusted, unless you've figured out a way to mathematically prove P=NP. It's that your average application is allowed to trust all kinds of stuff it shouldn't, and is allowed access to pretty much the entire computer.
Really all it sounds like is a MAC layer, mandatory access control.
See http://en.wikipedia.org/wiki/Security-Enhanced_Linux for an implementation of this.
> Nothing can be truly trusted, unless you've figured out a way to mathematically prove P=NP
If P=NP, then problems that are easy to solve are easy to guess. Somebody solves this, you will probably be pink-slipped immediately and while driving home will be subsumed into a computronium spacetime bubble generated by the AIs waking up everywhere in real-time-trader's racks.
Reductio ad absurdam: every security measure adds complexity, and complexity means insecurity. Ergo, the system with the least security mechanisms much be the most secure, amirite?
Wrong. Adding complexity increases the attack surface of a system, but as long as it decreases the attack surface of all the other components of the system by as much, it is a net benefit. I've worked with chrooted applications on various platforms, MAC and jails under FreeBSD, and systrace under OpenBSD, and the admin overhead was agonising (notably, systrace was found to have some security issues). This sort of per-process virtualisation would seem to combine the best parts of the those three security approaches, and if they can manage to do it in a minimall painful way it'll be an extremely effective security tool.
Fingers crossed. Xen was good, but it was still a bit of a research project when it was unleashed on the world. Bromium seems to be planned from the get-go as a product rather than a paper, so I for one am reasonably optimistic
Either the article is overly simplistic, or these guys are missing something fundamental. I hope it's the former. Let's take the Excel example cited in the piece and suppose that i have some piece of Excel in my hand. So, the microVM let's Excel open that file, and then my file says, "hey, User! Is it ok if I update the data linked in this spreadsheet?". What happens then? If the user grants permission, some ODBC magic happens and somebody's SQL Server just got trashed. If the user denies permission, their boss will come round asking by the Q4 numbers haven't been pulled from the database and emailed to him. In short, ringfencing apps is great, but lives or dies by the actions of users.
on an admittedly short thinking too early in the morning... that this works best the user follows the paradigm of thinking about the data rather than the application which creates/modifies that data. Thus, clicking on a document opens that document with its associated program in a little fortress of its own, where opening the associated program directly would require access to anywhere the data might live.
It doesn't answer the question of 'save as', and I think it doesn't cope with, say, text files which could be created or edited by a dozen different programs, though, unless you have a byzantine permissions structure.
Probably I have misunderstood something fundamental.
In one of my jobs I had an Excel spreadsheet that was a container for a VBA application. It took a series of files in one directory and encrypted them using the command line version of PGP. How would such an application run with this security product.
A lot of commercial applications access things in other machines (e.g. a payroll application on a PC will access the main payroll files on a server). Unless a huge amount of rules get written to cope with each exception then the product will be unusable. Note also that some applications will only access some files very rarely (eg at year end or when an exception flag is triggered) so having a learning mode in the VM will not suffice.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
