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.
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.
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.
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.