Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape.

To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway.

Correct me if I'm wrong.

My goal was to make things more secure, not completely secure.

Previously, dodgy libs could read (and add) ssh keys into ~/.ssh/, take over my NPM account by fetching ~/.npmrc, grab a copy of my ~/.bitcoin/wallet.dat, and add a keylogger into my ~/.bashrc

Now, at least it has to break out of docker first.



> To me, this is kind of like saying you should just run stuff as root, because there might be a privelege escalation vulnerability which lets the code run as root anyway.

But I never said it was preferable to run directly on the host. There are other choices.

> My goal was to make things more secure, not completely secure.

There is no such thing as completely secure. The argument against docker is more along the lines of "is it really as secure as people think it is?"

> I've heared this too, but as far as I know it's only because there are potential bugs in the container software that allow the malware to escape.

I'm not sure docker was designed for the purpose of secure isolation, so if it fails to securely isolate, I'm not sure it would count as a bug.


Linux relies on a concoction of properly-configured kernel subsystems to provide some level of isolation for containerized processes, and systems like LXD and Docker try to patch up the gaps.

The cgroups interfaces don't offer much security stuff directly -- they're mainly about containing groups of process within certain resource consumption quotas, and afaik, don't really attempt to contemplate secure isolation directly.

LXD approaches this by adding a uid/gid translation layer, so that the uid/gid for anything within an unprivileged container will be offset by a specified value, e.g., calls with user ID 1000 in a container are made to present to the host as user ID 1000000. This comes with its own host of issues which LXD tries to hide.

The short answer is that if security is any type of priority for the system in question and you want to run containerized processes, you should use an OS that implements container security directly in the kernel, like FreeBSD with jails or illumos with Zones, instead of depending on getting exactly the right configuration between all the moving pieces in the Linux container stack.


I have no recent information, but about 10 years ago FreeBSD maintainers were telling people not to rely on jails for security.


A full VM seems somewhat of a better stance on this no ?


Only if you ignore why I'm doing this.

I could counter your "VM is better than container", with "Separate hardware is better than VM".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: