I cannot see what this has to do with security. At the end of the day, it is the data that attackers are after and the app needs to be able to access it whether it is virtualised or not.
Each part of your application needs access to some sub-part of your data, but if you isolate your app at the OS level and run a whole app server inside a VM, every part of your application can at least in theory access all your data.
If you sub-divide your app in separate zerovms, whether per-request, or split it up further into functional responsibilities, then you substantially reduce the attack surface by ensuring that an exploit against any one part of your application can only exploit the specific subsets of data it is allowed to work on.
You can do this without zerovm too, but the more you reduce the cost and difficulty of spawning a new vm or container, the more finely grained you can subdivide your application, and hence the fewer privileges each subset of your app will have.
This is wishful thinking at the moment. I understand perfectly well what that means but data is data. An application typically has access to all data and the fact that you run it through a VM doesn't change anything.
I can find this technology useful only in areas where you want untrusted 3rd-party code to run without worrying about what it will do.
Typically - yes, but we can change that. Application does not need to access all data, it happens because today any web application serves millions of requests and thousands of users, it needs to access all the data of all users at any time. When using ZeroVM you can serve one user and one request by one VM instance. Then you may explicitly define what data is accessible to that one VM instance. Yes, you can implement such controls in your application yourself, but we are just doing it for you, uniformly, on infrastructure level.
And about "3rd party code". If we have two developers, each works on a different module of the same application, isn't their code is "3rd party" to each other?
It is only "wishful thinking" is as much as people are usually lazy because the effort required to sandbox small pieces of code is prohibitive in most current platforms. But larger systems are already often layered in ways that layer access to data anyway (though often not intentionally for security).
Good luck with this approach. I am not saying you should throw away this - awesome technology btw - but rather impractical in many ways. You will find very little use-cases where you can apply this with direct benefit. In most cases this wont change a thing - only perhaps on highly specialised software.
Probably because it reduces the attack surface, instead of having to worry about a 0-day in ssh or similar, you can just worry about your application. Also if someone else on the machine gets compromised, I assume you are isolated from that also since the attacker is still contained inside that container.
Not only that. Each request is isolated in its own container. This way one user of your application cannot gain access to data of another user by simply exploiting an application bug.
That's assuming you lock down access at the level of the application instance. If you create an instance with permission to read all data, it doesn't matter that it's been created by a single request… it's still got permission to read everything. Not saying a single request instance isn't a win for security, but you'll have to build your app around this concept to get that win.
To make application truly multi-tenant you will need to adopt "share nothing" concept anyway. We just supply you with a "share nothing" infrastructure.
If you have to run a single database for multi-tenant application you're in for some real pain. For example: how will you shard it? How will you load-balance it?
ZeroVM approach to cloud is that "cloud is the database". ZeroVM sessions have transactional qualities: deterministic, isolated, can be rolled back, etc. Essentially we integrate distributed storage with "stored procedures" and "triggers", this is what ZeroVM cloud looks like.
Comments
I cannot see what this has to do with security. At the end of the day, it is the data that attackers are after and the app needs to be able to access it whether it is virtualised or not.
Each part of your application needs access to some sub-part of your data, but if you isolate your app at the OS level and run a whole app server inside a VM, every part of your application can at least in theory access all your data.
If you sub-divide your app in separate zerovms, whether per-request, or split it up further into functional responsibilities, then you substantially reduce the attack surface by ensuring that an exploit against any one part of your application can only exploit the specific subsets of data it is allowed to work on.
You can do this without zerovm too, but the more you reduce the cost and difficulty of spawning a new vm or container, the more finely grained you can subdivide your application, and hence the fewer privileges each subset of your app will have.
This is wishful thinking at the moment. I understand perfectly well what that means but data is data. An application typically has access to all data and the fact that you run it through a VM doesn't change anything.
I can find this technology useful only in areas where you want untrusted 3rd-party code to run without worrying about what it will do.
Typically - yes, but we can change that. Application does not need to access all data, it happens because today any web application serves millions of requests and thousands of users, it needs to access all the data of all users at any time. When using ZeroVM you can serve one user and one request by one VM instance. Then you may explicitly define what data is accessible to that one VM instance. Yes, you can implement such controls in your application yourself, but we are just doing it for you, uniformly, on infrastructure level.
And about "3rd party code". If we have two developers, each works on a different module of the same application, isn't their code is "3rd party" to each other?
It is only "wishful thinking" is as much as people are usually lazy because the effort required to sandbox small pieces of code is prohibitive in most current platforms. But larger systems are already often layered in ways that layer access to data anyway (though often not intentionally for security).
Good luck with this approach. I am not saying you should throw away this - awesome technology btw - but rather impractical in many ways. You will find very little use-cases where you can apply this with direct benefit. In most cases this wont change a thing - only perhaps on highly specialised software.
Probably because it reduces the attack surface, instead of having to worry about a 0-day in ssh or similar, you can just worry about your application. Also if someone else on the machine gets compromised, I assume you are isolated from that also since the attacker is still contained inside that container.
Not only that. Each request is isolated in its own container. This way one user of your application cannot gain access to data of another user by simply exploiting an application bug.
That's assuming you lock down access at the level of the application instance. If you create an instance with permission to read all data, it doesn't matter that it's been created by a single request… it's still got permission to read everything. Not saying a single request instance isn't a win for security, but you'll have to build your app around this concept to get that win.
To make application truly multi-tenant you will need to adopt "share nothing" concept anyway. We just supply you with a "share nothing" infrastructure.
I am not able to wrap my head around this.
If I have to run a database, say postgresql, how do I run it? Inside the ZeroVM or outside? To run the DB I would need to give it file system access?
Now if there is a security hole in postgresql, how is it guaranteed that files other than DB files are never accessed?
If you have to run a single database for multi-tenant application you're in for some real pain. For example: how will you shard it? How will you load-balance it? ZeroVM approach to cloud is that "cloud is the database". ZeroVM sessions have transactional qualities: deterministic, isolated, can be rolled back, etc. Essentially we integrate distributed storage with "stored procedures" and "triggers", this is what ZeroVM cloud looks like.
Typically it takes a single request to dump various data via SQL injection. Just saying.