On Aug 23, 4:51 pm, Alex Clemesha <cleme...@gmail.com> wrote:
> On Fri, Aug 21, 2009 at 5:56 PM, Yoav Aner<y...@gingerlime.com> wrote:
>
> > Sounds like a great idea to me to de-couple the notebook from sage.
> > Appengine is not the only option though (but maybe the cheapest at
> > least for now), you could probably use an Amazon EC2 instance just as
> > easily (and with some more facilities at your disposal, having a
> > virtual server running).
>
> > Some more input from a security perspective: De-coupling the notebook
> > and the processing engine is is one of the key recommendations on my
> > threat model (http://groups.google.com/group/sage-devel/browse_thread/
> > thread/4bf627a69e0401c0 more details will be available soon as I hope
> > to complete a draft of the entire paper, or the final version due by
> > 4th September).
>
> I just read your paper
> (http://www.gingerlime.com/sageNotebookThreatModel.pdf),
> and it's very impressive how in depth you go, nice job.
Thanks. I'm hoping to post a better and full draft of the MSc project
paper very soon.
>
> I wanted to point out a couple of things related to de-coupling the notebook
> from sage, and the current security situation in the sage notebook.
>
> A good portion of the 'security' related code (HTTP sessions) in the
> sage notebook was written by
> me (see 'sage/server/notebook/avatars.py' or
> 'sage/server/notebook/run_notebook.py', etc)
> and is old and crufty, and probably has some security vulnerabilities.
> I've long since realized that trying to
> write you own http sessions framework is a bad idea (obviously).
>
> As you point out, decoupling the notebook from sage, and using more
> well established
> frameworks (like Django) is an excellent way to improve security
> because you have hundreds
> to people testing, using, and writing the code for you. In fact, I
True, but don't take django's security for granted. On the positive
side, it's more likely django will get the necessary security
'attention' as so many people rely on it, but then also attackers will
be more motivated to try to poke holes at it. Overall, my personal
feeling is that it is the right direction. It provides a more solid
and extensible framework to rely on, particularly with regards to
using different authentication and authorisation options.
> have started a project
> called codenode (used to be called Knoboo, or sometime badly spelled as
> Knooboo)
> that is exactly what you speak of: a de-coupled sage notebook that use Django.
> See here:http://codenode.organd here:http://github.com/codenode/codenode
Codenode looks very sleek. Please forgive my ignorance, but why are
there two projects? or perhaps, looking from a different angle, why
doesn't sage simply use codenode as the front-end? I see there's a
very healthy collaboration between the two projects, so wouldn't it be
more sensible to join forces here, rather than maintaining two
'versions' of the notebook?
>
>
>
> > As far of having notebook running on appengine. It would probably be
> > more straight-forward to use Robert's model - i.e. user->notebook on
> > appengine->sage backend. Otherwise issues like user authentication
> > (token mangement), synchronisation etc sound like a potential
> > nightmare to me. This 'standard' architecture still has its own
> > issues, particularly with appengine. I don't believe google allows to
> > initiate ssh connections to a backend (for the pexpect interface),
> > only web-based requests. Google also try to push users to have a
> > google account to authenticate. It might be a good or a bad thing,
> > depending on your perspective. Amazon EC2 in that respect gives you
> > more flexibility I believe. I would personally avoid either from a
> > vendor lock-in perspective, but that's just me.
>
> One of the "backends" of codenode can be google app engine, which
> is awesome because you get the security benefits that comes along with
> running arbitrary code on google's servers. You can try it out
> right now here:http://live.codenode.org
That's a very good idea from a 'short-term' security perspective, as
google seem to have done a good job at placing security around
untrusted code - and they take the risk to a great extent (if someone
tries to run malicious code - it runs on google). The downside is of
course the fact that you're locked into google. If users do try to run
malicious code, they might block your account, they might ask you to
pay increasing fees over time, and there's no real competition to
their service at the moment. So from a slightly longer term security
perspective, you might be better off developing your own security
mechanisms that you could port and use with any hosting provider and
using a generic service.
>
> Additionally, codenode works fine using EC2 as a backend as well.
> In fact, the backend of live.codenode.org used to be EC2, but it was a little
> expensive, so we are using app engine for the time being (even though
> app engine is more limited). EC2 is essentially just a
> "full capabilities virtual machine instance" that is no different that running
> (say) a Virtualbox or VMware instance on servers that you own yourself.
There are many virtual hosting providers out there at a more
competitive prices than EC2. You may not get the same availability and
flexibility (you pay monthly rather than per hour). I have used and
can personally recommend linode in the US, and xencon in Germany, both
are Xen based virtual machines. From a 'product packaging' perspective
however, I suppose it's easier to build an amazon machine image which
people can then use(??), whereas if you set up your own virtual host,
you'll have to know how to set it up the server, download sage/
codenode onto it and install it. For some people that's not a problem,
but it might be harder for others.
>
>
>
>
>
> > Another plus point for google appengine in terms of security - you get
> > the added security that the appengine provides over and above standard
> > python and you 'offload' any security problems with the notebook
> > itself to google. However, if someone does hack your notebook, not
> > sure whether google will simply shut you down (they probably will). Of
> > course it only applies to the Notebook code itself, and even then it
> > won't solve any XSS issues for you. It obviously won't help with any
> > security issue relating to the backend either, which is where the sage
> > 'soft-spot' is currently.
>
> > Unrelated to appengine, using a web framework like django is a good
> > idea from a security standpoint. It should give you much more
> > flexibility in terms of user authentication and authorisation with
> > many backend support. That alone would make a good security
> > improvement too.
>
> Completely agreed. I invite you to check out codenode in more detail.
> You can get started by typing "easy_install codenode", or check out the
> latest code athttp://github.com/codenode/codenode
Will do. Can't promise I'll have the time to run through the same
threat modelling process as I did for Sage (it is an MSc project paper
after all and I've spent a few months working on it), but I'll be
happy to help if I can. On a high level, I imagine that the threats
and issues Sage is facing are very similar - identical some times, to
the ones you'll need to consider for codenode.
>
> -Alex
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
