Cloud Python

Cloud Python is a server/client framework for running clients' python code on the server.

Projects Goals

1. The main goal of the project is a secure design & implementation.

   • The server should be protected from malicious clients
   • The clients should be protected from a malicious server
   • The clients should be protected& isolated from each other.

2. Cost: The projects attempts to use as much open source software and free softwre (free as in beer) where a compromise is needed.

3. Availability: the server shall be protected as much as possible from "Denial of Service (DOS)" attacks, as much as free resources allow for.

4. Simplicity as design goal. The project shall focus on what is required and will avoid feature creep.

Non goals

The following are a list of non goals:

• Scalability: Altough it is required to assure Availability goal, it is impossible within to make without payments made to a third party.

• Anonymity: Users are only identified via verified email address

• Ease of use: UX is not prioritized

• Computation as a service: the server may refuse to make CPU/GPU (or other resource) heavy operations, and users requests will time out after an arbitrary time selected by the server, without delivering even partial results.

• Generic: No support for multiple versions of Python runtime

• Generic: No support for running "any" kind of python code. Examples:

  • libraries which are not builtin will not be importable
  • no support for python "applications" - only single scripts.

• Network: hosted code cannot communicate

• Cross Platform: The implementation may focus on the Linux OS.

• The project may include multiple programming languages in use by the server software and one or more various client softwares.

The code is entirely open source so that it may be forked should these non-goals not be agreed upon.

API

The server software exposes the a REST API over an HTTPS connection, with both requests and responsed as json objects.

Any successfull request will be responded with the a json object with the attribute error=ok.

Registeration

a valid input to the registration endpoint is of the following form:

{
    "email": "someuser@somedomain.tld",
    "password": "password"
}

Upon succesfull registration the server will respond with HTTP code CREATED (201), with more information available through the error field of the returned JSON object.

Upon registration, the user will be sent a link to the supplied email address, where he can find information on validating his email address.

Only if the user validates his email within 10 minutes, he is presented with instructions on importing a TOTP token into an app in his mobile device.

This token will be required for any future authentication with the server, additionally to email address and the password, serving as the second component in Two Factor Authentication (2FA) as "something you have".

Important:

Should the user specify an email address which is already registered, the server's response will be as if the registration is successful, while not sending an additional email to the registered user. There for it should be impossible to enumerate users registers to the service.

A legitimate user may differentiate between these scenarios by checking his inbox.

Authorization alongside Authentication

Authentication is covered by the previous segment, and is implemented by combining email+password+TOTP.

Authorization is done manually by an administrator. After a user's successfull email validation, an email is sent to the server's administrator, requesting an approval to use the service.

The administrator may approve or ignore the request, and without this approval, the user cannot use the "Code execution" endpoint.

Code execution

a valid input to the execution endpoint is of the following form:

{
    "email": "user@domain.tld",
    "password": "password",
    "data": "print('Hello World\n')",
    "totop": 256732
}

and the expected answer from the server would be HTTP status OK and the following payload:

{
    "error": "ok",
    "stdout": "SGVsbG8gd29ybGQK",
    "stderr": "",
    "exit_code": "AA==",
}

"stdout", "stderr", "exit_code" are transferred as base64 encoding of the script's outputs. The example above refers to a script that succesfully executed print('Hello World\n'), such that it has no stderr output and the exit code is the number 0.

For security reasons, the server shall take no responsibility on the encoding of the information generated by user's scripts, and does not assume or validate any format.

Upon request timeout (User's code took too long to finish) the response would be HTTP status OK and the following payload:

{
    "error": "request timed out"
}

Partial stdout/stderr is deliberately not returned to prevent abuse or API misuse.

HTTP status used as possible responses:

Name	Number	Meaning
OK	200	The request was succesfull
CREATED	201	The user already exists or just created - check you inbox
BAD_REQUEST	400	The request's format is invalid
UNAUTHORIZED	401	The user is not registered or authorized by admin, will not complete request
REQUEST_ENTITY_TOO_LARGE	413	The request's format is invalid
INTERNAL_SERVER_ERROR	500	The request's format is invalid