Well, you are piping remote code directly into a python kernel,[0] so the user can always run arbitrary code with local rights. It is possible to limit the local rights far enough to prevent anybody from doing something bad, so use cgroups to limit network bandwidth, file io and memory and cpu usage. (So that you can prevent users from DDoS your server or attack others through the IPython service.)
Second, defense in depth, you want to have some defense in place even in the presence of an exploit and the usual first line of defense would normally be, don't run arbitrary code. So that line is broken by design for IPython-a-a-S, the user can just copy the latest exploit into the IPython notebook. This suggests virtualization, so that you have one VM per user and the user needs to break out of the virtualization and out of the cgroups jail mentioned above, before he can do anything interesting. (It has also the benefit, that user management is somewhat simplified.)
So overall, I guess it can be done, but needs a focus on security.
[0] this suggests the notion of an interpreter breakout. Yes this is a joke.
Second, defense in depth, you want to have some defense in place even in the presence of an exploit and the usual first line of defense would normally be, don't run arbitrary code. So that line is broken by design for IPython-a-a-S, the user can just copy the latest exploit into the IPython notebook. This suggests virtualization, so that you have one VM per user and the user needs to break out of the virtualization and out of the cgroups jail mentioned above, before he can do anything interesting. (It has also the benefit, that user management is somewhat simplified.)
So overall, I guess it can be done, but needs a focus on security.
[0] this suggests the notion of an interpreter breakout. Yes this is a joke.