doc for web server installation

[Denis]

I set up the Sage jupyter server at work to run behind an nginx reverse proxy, so I can approach it from home. The main reason is that the machine at work is 2-3x faster, not an uncommon situation I believe.

I wonder if there would be any interest to write a doc in the installation section, something like a case study, for those in a similar position. I would emphasize the security issues in particular, on the other hand I am not at all sure I have mastered them properly myself, so there would have to be some serious review if I open a ticket.

Any thoughts welcome,

Denis

[Markus Wageringel]

Hi Denis, I am not sure if this helps with your use case, but something I occasionally use to run Jupyter on a remote machine is a command like this:

ssh -L localhost:8888:localhost:8888 REMOTE -t sage -n jupyter --no-browser --port=8888

[Denis]

Hi Markus,

well, that would be the non-paranoic approach, to put it mildly. Generally speaking, it is against best practices to expose the server of a web application to the open internet. This is true even for a CMS like Plone, let alone Jupyter, which is intended for execution of arbitrary code. So that is in effect what my doc would be about, describing how to reach the Sage server through a front end specialized for the internet, nginx in particular, because that is what I used.

Admittedly the probability of attack against someone doing like you is pretty low, especially if you shut down Sage after use. So I have my doubts about how interesting the doc would be for the general user, hence this post.

[Dima Pasechnik]

On Wed, Apr 8, 2020 at 6:18 AM Denis <denis...@gmail.com> wrote:
>
> Hi Markus,
>
> well, that would be the non-paranoic approach, to put it mildly. Generally speaking, it is against best practices to expose the server of a web application to the open internet.

IMHO this is not exposing the server to "open internet", this is
allowing your client machine (at home), and only it (using "bind
addess), to access your server --- which, normally speaking, is behind
a firewall that does not allow any connections to it, expect perhaps
on the ssh port.

cf. https://www.ssh.com/ssh/tunneling/example

> This is true even for a CMS like Plone, let alone Jupyter, which is intended for execution of arbitrary code. So that is in effect what my doc would be about, describing how to reach the Sage server through a front end specialized for the internet, nginx in particular, because that is what I used.
>
> Admittedly the probability of attack against someone doing like you is pretty low, especially if you shut down Sage after use. So I have my doubts about how interesting the doc would be for the general user, hence this post.
>

> --
> You received this message because you are subscribed to the Google Groups "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/239cb259-1be0-4b10-8878-888e5f645295%40googlegroups.com.

[Denis]

On Wednesday, April 8, 2020 at 4:11:05 AM UTC+2, Dima Pasechnik wrote:

IMHO this is not exposing the server to "open internet", this is
allowing your client machine (at home), and only it (using "bind
addess), to access your server --- which, normally speaking, is behind
a firewall that does not allow any connections to it, expect perhaps
on the ssh port.

cf. https://www.ssh.com/ssh/tunneling/example

I agree, but I said "generally speaking," though I admit the inference was there, sorry about that. If Markus' one-liner is not in the installation docs, it should be, I think.  In any case, the docs are not for people who would get it right on their own, but for the others.

As I see it, the larger issue is that web applications need to have a web server embedded simply because they want a browser for a front end, just as they used a terminal in the old days. Admittedly the Jupyter developers have gone to some length to account for the possibility that their server would be used alone over the internet, supporting encryption in particular.

Speaking generally again, at least according to my reading, best practices are unequivocal: one should not use the web application's embedded server other than locally, i.e. when the browser is just a terminal. The idea is for application developers to concentrate on the application, and server developers to concentrate on the interaction with the internet. The only front ends considered internet-capable in this context are Apache, 2/3 of implementations, and nginx, 1/3.

For the case at hand, I am the first to admit that my solution is overkill. The reason is that the "attack surface" is very small, especially if (I repeat) one shuts down the Sage server after each session. A good idea would also be to approach it with a dedicated browser instance, to prevent cross-site scripting attacks. Also, with a universal web server comes the possibility of seriously misconfiguring it. It is a bit like that old question about memory management, is it too important to leave to the compiler, or too important to leave to the programmer?

So I rest my case, repeting the question: does it make sense to write such a doc, or not?