Readit NewsThat's it.
Deleted Comment
The company no longer exists so you can find at least some of them mirrored here:
https://chompie.rip/Blog+Posts/
The Firecracker, io_uring, and ebpf exploitation posts.
Chompie was my employee and was the one who did the exploitation, though I'd like to think I was at least a helpful rubber duck, and I did also decide on which kernel features we would be exploiting, if I may pat myself on the back ever so gently.
I meant that it's over-reach to say it's completely trustworthy just bc it's written in a GC/borrow checked language.
1. If using firecracker then you can't do nested virtualization
2. You still have the "os in an os" problem, which can make it operationally more complex
But Kata is a great project.
The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself. Containers are not insecure/composed with VMs to protect against memory safety issues so much as to implement sandboxing preventing these syscalls from doing bad shit.
I am extremely familiar with containers, the linux kernel, and virtual machines. In particular from a security perspective.
> The kernel itself does very little to prevent containers from interacting with the host (yes, via syscalls) in a way that affects other containers or the host itself.
Namespaces, such as process namespaces, file namespaces, user namespaces, etc, will prevent a container from interacting with another container without even getting into the fact that you can leverage DAC to do so further.
Rust is a good language and I like using it, but there's a lot of magical thinking around the word "safe". Rust's definition of what "safe" means is fairly narrow, and while the things it fixes are big wins, the majority of CVEs I've seen in my career are not things that Rust would have prevented.
The easiest way to escape a container is through exploitation of the Linux kernel via a memory safety issue.
> C-level memory stuff is absolutely NOT the reason why virtualization is safer
Yes it is. The point of a VM is that you can remove the kernel as a trust boundary because the kernel is not capable of enforcing that boundary because of memory safety issues.
> but there's a lot of magical thinking around the word "safe"
There's no magical thinking on my part. I'm quite familiar with exploitation of the Linux kernel, container security, and VM security.
> the majority of CVEs I've seen in my career are not things that Rust would have prevented.
I don't know what your point is here. Do you spend a lot of time in your career thinking about hardening your containers against kernel CVEs?
Dead Comment
> But damn, if Linux had been built with safety in mind security would be a lot simpler. Being able to trust the kernel would be so nice.
For its time, it was built with safety in mind, we can't hold it to a standard that wasn't prevalent until ~20 years later
We can agree that C was definitely the language to be doing these things in and I don't blame Linus for choosing it.
My point wasn't to shit on Linux for its decisions, it was to think about a hypothetical world where safety built in from the start.
Yes, I literally led a team of people at a FAANG doing this.
You're saying the easiest way to escape a container is a vulnerability normally priced over 1 million USD. I'm saying the easiest way is through one of the million side channels.
I'm not looking to argue, I was just annoyed that I was getting so many of the same comments. It's too early for all of this negativity.
If you want to discuss this via an avenue that is not HN I would be open to it, I'm not looking to make enemies here, I'd rather have an earnest conversation with a colleague rather than jumping down their throats because they caught me in the middle of an annoying conversation.