<div dir="ltr"><div><div>Thanks for sharing how sagemath has done it. I'm also aware of <a href="https://github.com/cni/ipython-hydra">https://github.com/cni/ipython-hydra</a> which authenticates IPython sessions via LDAP.<br>
<br></div>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.<br>
<br></div>Anyone else have any experience of configuring up a similar setup? Did you harden the notebook against malicious ipynb creators?<br><div><br></div><div>Thanks for any insight.<br></div><div><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On 19 September 2013 07:30, William Stein <span dir="ltr"><<a href="mailto:wstein@gmail.com" target="_blank">wstein@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Wed, Sep 18, 2013 at 9:12 PM, MinRK <<a href="mailto:benjaminrk@gmail.com">benjaminrk@gmail.com</a>> wrote:<br>
> On Wed, Sep 18, 2013 at 9:06 PM, Suminda Dharmasena <<a href="mailto:sirinath@sakrio.com">sirinath@sakrio.com</a>><br>
> wrote:<br>
</div><div class="im">>> What is the level of security and sand boxing built in notebook so that<br>
>> the Python scripts write cannot evoke any dangerous applications. E.g. use<br>
>> kernel or system functions, write or read to disk, make network connections,<br>
>> etc.<br>
><br>
> There is none at all - a logged in notebook has full access to do anything<br>
> they want as you on the system.<br>
><br>
>> If notebook is to be used on a web facing front end project accessible to<br>
>> everyone this will need some thinking about.<br>
<br>
</div>I thought about this problem recently [1].     In case anybody is<br>
interested, here's what I've done for  <a href="https://cloud.sagemath.com" target="_blank">https://cloud.sagemath.com</a>;<br>
which might be similar to what's done with <a href="https://www.wakari.io/" target="_blank">https://www.wakari.io/</a><br>
(another site that hosts ipython notebooks hopefully securely).   In<br>
cloud.sagemath the security model is that each user can create many<br>
projects, and in turn each project can also have many collaborators.<br>
Technically, a project is exactly the same thing as an account on a<br>
Linux box -- and project collaborators have *full* access to this<br>
Linux account (just like users on Amazon EC2 have full access to their<br>
VM's).     Right now projects run in one of many VM's, but without<br>
much further isolation; in the future, they will live in LXC<br>
containers in a VM.<br>
<br>
When a user opens an IPython notebook in cloud.sagemath, an IPython<br>
notebook server is started in their project as that user (if one isn't<br>
already running for the directory containing the file), and set to<br>
listen only on the *external* network interface of that virtual<br>
machine; in particular, the notebook server does not listen on<br>
localhost.  The VM's are firewalled, so they can't connect to ports<br>
above 1023 between each other.  This way no other user on any other VM<br>
(or localhost) can connect to the IPython notebook server directly, so<br>
its not necessary to use IPython's own login/password support or SSL<br>
support.<br>
<br>
Connections to the IPython notebook server happen via the following<br>
pathway (with everything after stunnel going over an encrypted VPN):<br>
<br>
           client --> stunnel --> haproxy --> node-proxy --> ipython<br>
notebook server<br>
<br>
Here node-proxy is an HTTP proxy server written in node.js, which<br>
consults a database to decide whether the given client is allowed to<br>
connect to the given project.  If so, the proxy is created; if not,<br>
they get an error.  Also, haproxy does load balancing across many<br>
different proxy servers.<br>
<br>
The upshot is that you can share ipynb's with a specified list of<br>
other users, and access is limited to only those users. However, each<br>
user has their own credentials.<br>
<br>
[1] <a href="http://sagemath.blogspot.com/2013/09/ipython-notebooks-in-cloud-with.html" target="_blank">http://sagemath.blogspot.com/2013/09/ipython-notebooks-in-cloud-with.html</a><br>
<span class="HOEnZb"><font color="#888888"><br>
 -- William<br>
<br>
--<br>
William Stein<br>
Professor of Mathematics<br>
University of Washington<br>
<a href="http://wstein.org" target="_blank">http://wstein.org</a><br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
IPython-dev mailing list<br>
<a href="mailto:IPython-dev@scipy.org">IPython-dev@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/ipython-dev" target="_blank">http://mail.scipy.org/mailman/listinfo/ipython-dev</a><br>
</div></div></blockquote></div><br></div>