Comment by ericbarrett
5 years ago
Look, my friend, we will have to disagree on this. What exploits will attack this setup from the front? A Linux networking or other syscall RCE, a Go compiler intrinsic RCE, a vulnerability in the app code, or a vulnerability in a third party library. All of which exist in the common OS-hosted scenario, in addition to everything else, plus you have both your container and your OS to worry about (e.g. openssl).
EDIT: Anyway, I'd like to thank Mr. Bogdanov and his client for sharing this story—it's just fascinating.
Sounds like a pretty nice way to get around having to constantly patch minor CVEs in base OS/distributions to maintain compliance - cut out the OS entirely.
No, it's not. You can deploy a very minimal Linux while also keeping the services that are actually good for security, like logging, IDS/IPS, certification compliance tooling, monitoring.
Unless you are running unnecessary daemons exposed on the Internet, 99% of the attack surface is from your application and the kernel itself.
Both parts that you can't remove.
> This is a strawman. A shared hypervisor opens another attack surface and was not part of the discussion.
Not to worry. When the ghosts knock, you just have to remind them that their attack is out of scope /s