AWS Firecracker Open Source: Secure and Fast MicroVM for Serverless Computing | Hacker News Reader

AWS Firecracker Open Source: Secure and Fast MicroVM for Serverless Computing

aws.amazon.com

72 pointsareski11 comments

Duplicate of https://news.ycombinator.com/item?id=18539539

New, secure, VM..

    sudo chmod 777 /dev/kvm

But... but... almost.

We asked for the blog to be corrected to match the official recommendation from the engineering team (as it was presented in Jeff's blog at https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...)

The post was updated within 16 hours from the original post date.

Oh dear. Given the audience for this article I'd assume that readers know that this configuration is not suitable for production... but then again it would probably be a good idea for the article to state that!

Hi, I work at AWS and before that on KVM since it was a thing.

Restricting /dev/kvm these days doesn't make much sense. The interface is designed to be safe for any user. The fact that we started as a character device and not syscalls is just a historical decision.

Thank you, I have learned something new! I believed it was somewhat similar to having access to the Docker socket and I was always sure to restrict it. Everyone please ignore me.

Except... Amazon itself says that it's been used in production for a while...

I imagine a competent sysadmin deploying this won't just blindly copy/paste the `chmod 777` command into their terminal... this is likely just a "quick, getting started" sort of thing.

Since only the Firecracker user needs read/write access, it would be trivial to limit that to just the Firecracker user or group.

So apparently on another page on their site they are using "sudo setfacl -m u:${USER}:rw /dev/kvm" instead. Too confusing. Source: https://aws.amazon.com/blogs/aws/firecracker-lightweight-vir...

From the announcement: Built-In Security: We provide compute security barriers that enable multitenant workloads, and cannot be mistakenly disabled by customers. Customer workloads are simultaneously considered sacred (shall not be touched) and malicious (shall be defended against).

Step one, here is a guide that effectively removes all protections on the host system.

Win.

I've been caught by this also: I read it as 'chmod 777 /dev/kmem' which brings me a knee-jerk horror reaction.

Reply on news.ycombinator.com