(demo) server security

[koo5]

• swipl is and will be exploitable. we get memory errors regularly. it's necessary to isolate it from the rest of the system.
• • if we don't make some drastic change, like switching to a different solver altogether, it must be accepted that the prolog code could leak.
• lodgeit-labs/accounts-assessor#178
• • we'll need to review Arelle
• • we'll need to review our taxonomy fetching code
• each prolog worker would probably best be spawned in a separate docker container, to have no access to the rest of the system
• internal_services should require a token parameter
• we should probably stop running django in dev mode
• credentials will be stored above repo level in secrets.sh
• • included from run.sh's
• • make sure to use the full word "PASSWORD" in password variable names, so django doesn't print them in backtraces
• • maybe turn env vars into python vars in settings.py?
• we don't have https set up, it's necessary to remember to admin agraph only through a tunnel
• fail2ban should be set up, for agraph
• demo server should be moved to a dedicated server, away from our dev box

[koo5]

i dislike mod_wsgi: 1) it's still too much in development, and not a big team. It's C code, so vulnerabilities are likely. If we use the ubuntu packaged version, we are probably stuck with default ubuntu python version. alternative: proxying relevant uris through apache, django running standalone. Possibly single dedicated root uri, let's say request/.

[koo5]

https://github.com/GrahamDumpleton/mod_wsgi-docker/issues/34 warpdriive seems to be alive. or: https://github.com/carlostighe/apache-flask

[koo5]

i'm finding the docker stack/swarm/compose jungle rather suboptimal for managing deployment even just on my dev machine. But this is probably evolving in the right direction: https://www.docker.com/blog/simplifying-kubernetes-with-docker-compose-and-friends/ https://skaffold.dev/

otoh, the whole situation with security updates in docker, and the whole culture of maximally minimal images configured by tweaking lenghty bash command lines..meh https://news.ycombinator.com/item?id=10782897 https://github.com/docker-slim/docker-slim (not relevant but nice)

better way to run python webapps? : https://github.com/phusion/baseimage-docker#whats_inside https://github.com/phusion/passenger-docker

[koo5]

also todo https://github.com/lodgeit-labs/accounts-assessor/issues/17

[koo5]

to support trusted users

basicauth everything

• /chat
• /upload

to support untrusted users

dont trust swipl

use docker api to restart worker after every request

• can a restart api be exposed without exposing everything?
  • proxy control service
  • g "untrusted docker worker"
  • frontend server passess request file to this, and this passess them to worker as some kind of private volume?
  • then just prints results to stdout
• /tmp only for debugging files. result files bodies part of result.n3
• assume frontend_server isnt hacked
• dont assume worker will restart itself
• or just never give two jobs to one worker instance
• move exchange rates fetching/caching into internal_services
• worker wouldn't invoke any commands

dont trust django dev server

use https://github.com/phusion/passenger-docker instead of django dev server

dont trust arelle

fix arelle etc issues (github issue)

[koo5]

this issue is partly outdate but still a great overview.

some more points:

• minimize attack surface of services server. Replace generic "run shell" with specific "symlink one file in owner's tmp to another"
  • but for that, we cannot trust the worker to give the true user id, we need to have frontend server sign a jwt, and have services verify it

[koo5]

summed up (WIP) and continued in wiki/Security.md

[koo5]

done for now

[koo5]

except the bit about security updates of services deployed via docker-compose etc, this is a general problem.