Secure a server on `localhost` such that only the authorized users can connect

Question

Consider an application (such as an IPython notebook) that runs an HTTP server, and that (by design!) allows arbitrary code execution by authenticated users (this is the entire point of IPython, Jupyter et al, and is not a bug).

Clearly, it is a disaster for any user to be able to authenticate OTHER than the user the server is running as.

This can be done by ensuring that only the authorized user can supply proper credentials, and by ensuring that these credentials are only supplied to the appropriate server.

I would like to handle this in an entirely automated way.

The ideal solution seems to be TLS server and client certificates. The problem is that this requires manual, awkward setup. I want there to be no manual setup – just something that can be run by the server itself.

Note: the server is running as the same user as the client, so it has write access to the directories that the client browser uses to store per-user configuration. It is not running as a privileged user, so it can't modify firewall rules.

A perfect solution would be a way to enforce a specific server certificate and provide a server-specific client certificate, all controlled (externally) by the server process (which is just a command line program that runs an HTTPS server).

No, the server cannot run as an unprivileged user. It is really an IDE that uses the browser as a GUI. It needs to be able to execute arbitrary code with the privileges of the invoking user. Hence the need for absolutely secure authentication.

Yes, I can reject connections that are not from 127.0.0.1. This does not help against local attackers by other users on the same machine.

Is this possible, or will I need to embed a browser? I don't think the Chromium Embedded Framework would help, as it does not handle control of TLS certificate trust.

Answer 1

Assuming you can manipulate the code of both the server applications, simply drop a random value into a file only readable by the running user at startup of the server, then use that as an authentication token (either directly or as the salt for the response to a challenge). You could, for example, set an http password at startup using a simple script and drop the plain text into a file. But like the client cert, the process of getting the data into the client remains manual.

The only way to get this working transparently to the user without rewriting the client would be to configure a web application for use by all authorized users which populated a token into a cookie on the browser, then wrote a server config file which required that specific cookie to connect and which listened on an assigned port then started the server running as the identified user which therefore implies re-authenticating first, using the OS's authentication mechanism. However this means giving a lot of privilege to the master server instance and the complication of integrated authentication. But managing the ports and processes will be a nightmare.

Can't you just give them VMs?