SEC: Programs should run without filesystem write privileges

[westurner]

Note: for support questions, please use the cookiecutter-django tag on stackoverflow. This repository's issues are reserved for feature requests and bug reports. If you need quick professional paid support for your project, contact support@cookiecutter.io.

• I'm submitting a ...

  • bug report

• Do you want to request a feature or report a bug?

I think this is a security vulnerability?

• What is the current behavior?

Apps run as django or root in the docker containers. With these users, they have write permissions with which they could overwrite themselves, use raw sockets, etc.

• If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem

docker-compose -f local.yml up

• What is the expected behavior?

I think there should be a third user account (root, django (rw), 'app' (r)) with the least permissions necessary to run.

• What is the motivation / use case for changing the behavior?

https://en.wikipedia.org/wiki/Principle_of_least_privilege

This is a really common error with Docker containers.
Just because it's in a container doesn't mean that just running as root is okay.

• Please tell us about your environment:

https://pkgs.org/download/container-selinux

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)

Would adding a third user to a group with read permissions be sufficient?
It may require a bit of explanation for users that want to write to the filesystem:
they should be explicitly granting those privileges
because secure by default.

[westurner]

See: #1304 "docker/celery exits because celery is run as root"

[jayfk]

First of all, just to make this clear for people stumbling upon this issue: This is about the development environment only. The production environment runs as non-root.

---

The main problem here is that this leads to a horrible development experience if implemented securely.

On questions like this, we really have to take a look at both sides: What's the exact threat and what do we loose if we do this in the most secure way possible.

I tend to think that in this case development comfort beats the need to make this as secure as possible. Don't forget that, even if you manage to gain shell access to the running root container, you still have to break out of it.

I'm happy to discuss this tough.