MATE currently isn't safe to expose to the public facing internet, and won't be without a decent amount of service hardening. We should document the current security considerations required during a deployment (even a private one).
An incomplete list of aspects that need to be documented (and potentially fixed):
MATE uses an access token and secret to establish a connection with the storage service (MinIO). It uses hard-coded ones by default, but users should update their .env file to set each to a long random string.
MATE's executor (Celery) service runs as root, with C_FORCE_ROOT=1 and Pickle-based serialization enabled. We do this to marshal Pydantic models correctly, but it's a potential security problem. We should either figure out a way to run as non-root (tricky?) or to get rid of our Pickle dependency (maybe less tricky?)
Compilation and build processes are not meaningfully isolated from MATE's core runtime: a non-containerized build/compilation can modify the executor service underneath it, including in ways that'll completely hose the system. Containerized builds are slightly more isolated, but still have access to the Docker socket and could potentially pivot to other services/escape their container.
MATE currently isn't safe to expose to the public facing internet, and won't be without a decent amount of service hardening. We should document the current security considerations required during a deployment (even a private one).
An incomplete list of aspects that need to be documented (and potentially fixed):
MATE uses an access token and secret to establish a connection with the
storage
service (MinIO). It uses hard-coded ones by default, but users should update their.env
file to set each to a long random string.MATE's
executor
(Celery) service runs as root, withC_FORCE_ROOT=1
and Pickle-based serialization enabled. We do this to marshal Pydantic models correctly, but it's a potential security problem. We should either figure out a way to run as non-root (tricky?) or to get rid of our Pickle dependency (maybe less tricky?)Compilation and build processes are not meaningfully isolated from MATE's core runtime: a non-containerized build/compilation can modify the
executor
service underneath it, including in ways that'll completely hose the system. Containerized builds are slightly more isolated, but still have access to the Docker socket and could potentially pivot to other services/escape their container.