Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Avoid running asterisk as root #8

Open
mwild1 opened this issue Sep 18, 2023 · 3 comments
Open

Avoid running asterisk as root #8

mwild1 opened this issue Sep 18, 2023 · 3 comments
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@mwild1
Copy link

mwild1 commented Sep 18, 2023

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
Copy link
Owner

mlan commented Sep 18, 2023

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
Copy link
Author

mwild1 commented Sep 18, 2023

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
Copy link
Owner

mlan commented Sep 18, 2023

@mwild1

You argue your point very well.

I will mark this as an enhancement request.

Many thanks for your input.

@mlan mlan added the enhancement New feature or request label Sep 18, 2023
@mlan mlan added the help wanted Extra attention is needed label Apr 23, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants