
Ask HN: Can tux.io rely on LXC's security? - christux
http:&#x2F;&#x2F;tux.io relies on LXC&#x27;s security - it gives the public access to non-root desktops in LXC containers.<p>To date, the worst that has happened are fork bombs.  (For which I now have a solution.)<p>Is it safe to rely on LXC&#x27;s security, provided that I keep the containers and hosts patches?
======
j_s
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-
cont...](http://rhelblog.redhat.com/2017/01/13/selinux-mitigates-container-
vulnerability/)

 _Abusing Privileged and Unprivileged Linux Containers (2016)_ |
[https://www.nccgroup.trust/globalassets/our-
research/us/whit...](https://www.nccgroup.trust/globalassets/our-
research/us/whitepapers/2016/june/container_whitepaperpdf/)

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
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
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.

