mlan/docker-asterisk

Avoid running asterisk as root

mwild1 opened this issue · 3 comments

mwild1 commented

From the Asterisk documentation:

Running Asterisk as root or as a user with super user permissions is dangerous and not recommended.

This dockerfile is great in many ways (indeed, the best I have found), but the resulting asterisk process runs as root. It would be great to follow best practices and run as a user with less privileges.

Most containers allow passing the desired UID/GID as variables, so that they can be configured to match the UID/GID of a host user (thus ensuring files in bind mounts get the correct ownership).

mlan commented

Hello @mwild1

Running processes as non-root is normally a good habit. Such practice limits the implications of exploits of security weaknesses.

When processes runs within a container they are isolated from the rest of the system and the implications of exploits are limited.

From this perspective I do not see a strong need to run software as non-root within containers.

You mention bind mounts. Is this your main reason to manipulate the UID/GID? What benefit do you see using bind mounts and not docker volumes?

mwild1 commented

Hi, thanks for the prompt response!

Unfortunately container isolation alone is generally not considered sufficient isolation for security best practices. Methods to escape container isolation have been identified (and fixed) in the past, and it is reasonable to expect that not all methods of escape have been found. Many such escapes require root access inside the container, as root has access to many kernel functions that unprivileged user accounts do not.

Projects such as gVisor exist specifically to improve the isolation of containers via sandboxing methods. However most people don't use such isolation layers, and they add overhead and complexity for most use cases.

Even if container isolation is perfect, you still want to protect the container environment itself, just as you would protect the host if asterisk were installed there. Having access to root allows an attacker who can execute code to perform a wide range of actions that unprivileged users cannot, such as privileged network access.

Some further reading on this topic:

mlan commented

@mwild1

You argue your point very well.

I will mark this as an enhancement request.

Many thanks for your input.