Closed techtonik closed 8 years ago
Well, the intent of that environment is to test LXD itself which comes pre-installed in the environment and is capable of reaching all of the default image servers.
Even if I wanted, I couldn't allow Github given that they don't support IPv6 and the test environment doesn't have IPv4 connectivity. But I'm also trying to keep the list of servers that someone can talk to from the environment as low as possible and have all of those either be run by me or by Canonical, so that should someone try to actively attack those servers from the test environment, I won't get in trouble.
What kind of attacks are possible there?
The usual kind you'd expect from giving a shell to random strangers on the Internet. Sending spam, attempting SQL injections, good old DoS, ... Port restricting to just SSH and GIT would prevent all the web attacks but people could still DoS my own internet connection by pushing a huge amount of data through and could still try to exploit Github's git server.
(This is all from past experience of running a similar environment with a lot less firewalling in place. I was getting about one abuse complaint forwarded by my ISP per day...)
Sending spam,
no mail interface
attempting SQL injections,
there are no databases in container to inject
good old DoS,
can containers have a throttling limitation to limit amount of resources consumed?
For spam and SQL, I'm talking about attacking the Github infrastructure, and they sure run databases there to store all their data which someone could attack.
And we can limit the download speed to slow down a DoS attack but that would also slow down downloading legitimate LXD images so again, not something we'd do.
So anyway, I'm going to close this because I have no intention to allow Github access in my firewall.
You are obviously welcome to host your own copy of the lxd-demo service which you can then let your users access whatever you want and deal with the consequences yourself.
I hoped to see example of fine-tuning LXD server for various security requirements, and running public container with such live restrictions is a good example of container reliability. Right now the overall feeling is that security restrictions are there because containers are not secure themselves and downloading non-reviewed code to them can lead to exploits.
I'm not sure why anyone would think that when we also allow incoming ssh access that they can use to push whatever they want to the container.
The network restriction is there just to avoid network abuse and everyone else I've talked to so far seems to have been understanding that part just fine.
It looks like it is impossible to clone stuff from GitHub even given that
git
is installed. That quite limits the things you can try.