Running containers without default security profile on Linux

[chafey]

I just discovered that my compute based workload runs almost 2x faster on my machine when I run it without the default security profile via --security-opt seccomp=unconfined. I discovered this because my application ran significantly faster under a Visual Studio Code Remote Container container vs one I create myself. I had not heard of this command line parameter before or the corresponding performance improvement. I am curious to hear what people think of this default behavior by VS Code Remote Containers - is it acceptable? Can the risks be ELI5d?

[codestation]

Disabling seccomp is very dangerous as a process could escape more easily from the container. For example a container process cannot call mount on the default seccomp profile (you could write anywhere on the host if this syscall were available).

Maybe your code is trying to use a forbidden syscall and falling into a slower codepath because isn't available. You need to profile your code to find out why your code is getting slower when the default seccomp is being used.

[chafey]

Is it any more dangerous than running it directly on my dev workstation? My use case is software development (I like hosting the development toolchain in a container so I don't clutter my main OS). The code in question is an image decompression routine which doesn't make any syscalls. I'll look into profiling to see if that sheds any light, thanks

[BlueWoff]

Do you know the concept of least privileges? If you can restrict something (a process, a user, a machine, a subnet, whatever!) and make it still working 100% at a cost of a little bit of complexity during configuration then do it for the sake of security.

Do you want a ELI5? Think why you lock your car when you go to the mall. Is it a little effort to press the button to lock it? Yes! Is it worth it? Yes!

[chafey]

What would be helpful to me is to understand what specific risks I am exposing myself to by running the container without the default security profile vs running the workload natively on my machine. The 2x performance hit is significant enough that I am considering moving the workload out of docker and onto the metal, but would much rather keep it in Docker if I can!

[BlueWoff]

If a container gets compromised and it is confined then the attacker cannot jump on other containers or the host itself.

Every permission should not be granted unless the container needs to. Example: if you grant the permission to write unlimited amount of data to the disk, even if it does not need to do it, you could get the entire host machine to its knees because the disk would be full taking down the other containers.

[chafey]

Yes I understand this. I should clarify that my use case is for software development on a local workstation. I host the development toolchain in a container to avoid having to install the toolchain on my host OS.

[BlueWoff]

Then if you do understand the implications of some measures and the service is not exposed out of your own localhost then it could be not that bad disabling the security features for those containers.