Thu Sep 19 01:30:55 CDT 2013
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>
>> 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. use
>> kernel or system functions, write or read to disk, make network connections,
> There is none at all - a logged in notebook has full access to do anything
> they want as you on the system.
>> If notebook is to be used on a web facing front end project accessible to
>> 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
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.
Professor of Mathematics
University of Washington
More information about the IPython-dev