3 ms·

You should at least isolate all your containers from the host machine using a virtual machine. LXC security can doubtless be mis-configured; how much info can

by j_s 10y ago

You should at least isolate all your containers from the host machine using a virtual machine. LXC security can doubtless be mis-configured; how much info can you share regarding your setup? From a few minutes research it sounds like you need user namespaces and seccomp for starters. Redhat|OpenStack relies on SELinux much more than seccomp: https://news.ycombinator.com/item?id=14220503 https://news.ycombinator.com/item?id=14220503 http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-vulnerability/ http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-cont... Abusing Privileged and Unprivileged Linux Containers (2016) | https://www.nccgroup.trust/globalassets/our-research/us/whitepapers/2016/june/container_whitepaperpdf/ https://www.nccgroup.trust/globalassets/our-research/us/whit... You should get some free testing from your Show HN! https://news.ycombinator.com/item?id=14245447 https://news.ycombinator.com/item?id=14245447

christux 10y ago
Thanks for your comment. There is only one user, tux, which is uid 1002 and tux does not exist in the host's /etc/passwd. The users do not have root access in the containers. Cgroups is used to impose limits on RAM, number of processes, visible CPUs, etc. I made this site in evenings and weekends, and have put it up for the public to use. I want find out sooner, rather than later, if the whole idea is flawed.
- j_s 10y ago
  Here are two simple tips you should be able to implement right away (if you're not already doing this): https://dadario.com.br/preventing-docker-escaping-attacks/ https://dadario.com.br/preventing-docker-escaping-attacks/ > 1) Run the container as non-root user > 2) [Use] a read-only file system SELinux is probably your next step, which may be as simple as switching your host OS to RedHat/CentOS. I'm not sure if you'll be able to use a VM on your current host, and using only one VM to host all your containers will not protect users from each other. (You could eventually use 1 VM for all free customers + VM per random batches of mid-tier paying customers + VM per premium customer.) VM escapes are much more rare than container escapes, and should be a solid line of defense separating your stuff from your users. The discussion I referenced recommended libvirt.

by j_s 10y ago

christux 10y ago

Thanks for your comment. There is only one user, tux, which is uid 1002 and tux does not exist in the host's /etc/passwd. The users do not have root access in the containers. Cgroups is used to impose limits on RAM, number of processes, visible CPUs, etc. I made this site in evenings and weekends, and have put it up for the public to use. I want find out sooner, rather than later, if the whole idea is flawed.

j_s 10y ago
Here are two simple tips you should be able to implement right away (if you're not already doing this): https://dadario.com.br/preventing-docker-escaping-attacks/ https://dadario.com.br/preventing-docker-escaping-attacks/ > 1) Run the container as non-root user > 2) [Use] a read-only file system SELinux is probably your next step, which may be as simple as switching your host OS to RedHat/CentOS. I'm not sure if you'll be able to use a VM on your current host, and using only one VM to host all your containers will not protect users from each other. (You could eventually use 1 VM for all free customers + VM per random batches of mid-tier paying customers + VM per premium customer.) VM escapes are much more rare than container escapes, and should be a solid line of defense separating your stuff from your users. The discussion I referenced recommended libvirt.