# Disabling seccomp in docker containers for fun and profit.

> These posts are more "notes to self" than real blog posts. It is what it is..

Ran across a vague mention of **seccomp** having a negative effect on the execution speed of python (perl, ruby.. and so on and so forth) in docker containers.

My container with default **seccomp**

```sh
Pystone(1.1) time for 50000 passes = 0.474961
``` 


Rebuild the container with the **seccomp** incantation included in my docker-compose 
```docker-compose
...
   security_opt:
      - seccomp:unconfined
``` 
```sh
Pystone(1.1) time for 50000 passes = 0.212109
``` 

So, yeah. There has to be a real good reason as to why seccomp is enabled by default since execution time is slashed in half by disabling it!

My starting point for most of what I do is dokerized **postgreSQL**, **django**, **memcached** and **nginx** (expand as needed) in a **VPS** with an additional  **nginx** secured fronted.. behind a **firewall** with a hole punched through to **:443**

I might be wrong, but I don't see the security issues. I mean, if they manage to get access to my server I've got a much bigger problem than disabling **seccomp** - dont I?

Edit #2: I've come to understand that the **seccomp** situation is because of  [this](https://techbeacon.com/security/linus-torvalds-sums-intel-spectre-patch-fail-pure-garbage). 


> Is Intel really planning on making this **** architectural? Has anybody talked to them and told them? -- Linus Torvalds

Which sums it up nicely. You can either disable the kernel patch or disable **seccomp** in docker. 

As it stands now execution speed inside a container is a smidge better than out side and I'm gonna leave it at that. Now I have to start disecting my mini-kube to see what I can to about it.