3 ms·

So why would you use this over regular containers? Is this for people who think containers are insecure?

insanitybit 3y ago
Containers are not appropriate for some scenarios. If your threat model is "attacker has arbitrary code execution" you should be very wary of a container holding them for long - you're one kernel privesc away from a container escape. It's nice to have if your situation is "first the attacker would need to exploit my service and then they'd have code exec", but if you provide RCE as a service a normal container is just not a good barrier. By contrast, running attacker code in Firecracker is much safer - for one thing, the attacker needs to escalate within the VM in order to then expose the necessary primitives to then escape the VM. So it immediately adds an additional required vuln. But also, instead of the entire Linux kernel being the attack surface (it is for the first vuln, but...) you have to attack a much smaller codebase that implements the VM. In the case of Firecracker this is really hard and, depending on your exploit, if you end up controlling the Firecracker VM itself you're actually in yet another sandbox - so you now need another vuln to escape (although that sandbox is not amazing imo).
- symlinkk 3y ago
  But containers run everywhere. ECS for example. If they were insecure then half the web services we use every day would get hacked.
  - insanitybit 3y ago
    ECS is not using containers for isolation though. A single ESC cluster will only ever run on single tenant infrastructure. When AWS requires isolation they never use containers.
kbumsik 3y ago
Many serverless services use MicroVM rather because they think containers doesn't have enough isolation (=insecure?) to run untrusted code.
dharmab 3y ago
Run multiple workloads on the same CPU that you don't fully trust. VM-based containers will force the CPU to properly context switch between guests (e.g. using VMENTER on x86), normal process-based containers won't.

Containers are not appropriate for some scenarios. If your threat model is "attacker has arbitrary code execution" you should be very wary of a container holding them for long - you're one kernel privesc away from a container escape. It's nice to have if your situation is "first the attacker would need to exploit my service and then they'd have code exec", but if you provide RCE as a service a normal container is just not a good barrier. By contrast, running attacker code in Firecracker is much safer - for one thing, the attacker needs to escalate within the VM in order to then expose the necessary primitives to then escape the VM. So it immediately adds an additional required vuln. But also, instead of the entire Linux kernel being the attack surface (it is for the first vuln, but...) you have to attack a much smaller codebase that implements the VM. In the case of Firecracker this is really hard and, depending on your exploit, if you end up controlling the Firecracker VM itself you're actually in yet another sandbox - so you now need another vuln to escape (although that sandbox is not amazing imo).

symlinkk 3y ago
But containers run everywhere. ECS for example. If they were insecure then half the web services we use every day would get hacked.
- insanitybit 3y ago
  ECS is not using containers for isolation though. A single ESC cluster will only ever run on single tenant infrastructure. When AWS requires isolation they never use containers.

kbumsik 3y ago

Many serverless services use MicroVM rather because they think containers doesn't have enough isolation (=insecure?) to run untrusted code.

dharmab 3y ago

Run multiple workloads on the same CPU that you don't fully trust. VM-based containers will force the CPU to properly context switch between guests (e.g. using VMENTER on x86), normal process-based containers won't.