Thu Sep 19 02:56:59 CDT 2013
Thanks for sharing how sagemath has done it. I'm also aware of
https://github.com/cni/ipython-hydra which authenticates IPython sessions
I've been pondering how to go about setting up an enterprise installation
of IPython notebooks for 300+ internal scientific users with each of their
desktops hosting a single instance accessible by just one user (i.e. no
collaboration at this stage) available only on the internal network. For
me, the LDAP approach looks like the way to go, but there are other
security concerns (such as the automatic execution of Python from html at
notebook open time) which also make me a little nervous. My problem is that
for the notebook to be of any value to the users I support, it needs to be
running on their desktops, which by its very nature isn't as throwaway as a
garden walled VM.
Anyone else have any experience of configuring up a similar setup? Did you
harden the notebook against malicious ipynb creators?
Thanks for any insight.
On 19 September 2013 07:30, William Stein <email@example.com> wrote:
> On Wed, Sep 18, 2013 at 9:12 PM, MinRK <firstname.lastname@example.org> wrote:
> > On Wed, Sep 18, 2013 at 9:06 PM, Suminda Dharmasena <email@example.com
> > wrote:
> >> What is the level of security and sand boxing built in notebook so that
> >> the Python scripts write cannot evoke any dangerous applications. E.g.
> >> kernel or system functions, write or read to disk, make network
> >> etc.
> > There is none at all - a logged in notebook has full access to do
> > they want as you on the system.
> >> If notebook is to be used on a web facing front end project accessible
> >> everyone this will need some thinking about.
> I thought about this problem recently . In case anybody is
> interested, here's what I've done for https://cloud.sagemath.com;
> which might be similar to what's done with https://www.wakari.io/
> (another site that hosts ipython notebooks hopefully securely). In
> cloud.sagemath the security model is that each user can create many
> projects, and in turn each project can also have many collaborators.
> Technically, a project is exactly the same thing as an account on a
> Linux box -- and project collaborators have *full* access to this
> Linux account (just like users on Amazon EC2 have full access to their
> VM's). Right now projects run in one of many VM's, but without
> much further isolation; in the future, they will live in LXC
> containers in a VM.
> When a user opens an IPython notebook in cloud.sagemath, an IPython
> notebook server is started in their project as that user (if one isn't
> already running for the directory containing the file), and set to
> listen only on the *external* network interface of that virtual
> machine; in particular, the notebook server does not listen on
> localhost. The VM's are firewalled, so they can't connect to ports
> above 1023 between each other. This way no other user on any other VM
> (or localhost) can connect to the IPython notebook server directly, so
> its not necessary to use IPython's own login/password support or SSL
> Connections to the IPython notebook server happen via the following
> pathway (with everything after stunnel going over an encrypted VPN):
> client --> stunnel --> haproxy --> node-proxy --> ipython
> notebook server
> Here node-proxy is an HTTP proxy server written in node.js, which
> consults a database to decide whether the given client is allowed to
> connect to the given project. If so, the proxy is created; if not,
> they get an error. Also, haproxy does load balancing across many
> different proxy servers.
> The upshot is that you can share ipynb's with a specified list of
> other users, and access is limited to only those users. However, each
> user has their own credentials.
> -- William
> William Stein
> Professor of Mathematics
> University of Washington
> IPython-dev mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the IPython-dev