Running processes as root helps attackers

[szepeviktor]

Please consider avoiding root (UID 0) and system users (UID 1-999) e.g. www-data.
Least privileges come with normal users.

[jaydrogers]

I totally agree and this is on my radar.

I am hoping this will be fixed in #15.

The only problem I had was if I set it to www-data in this image, then later on I want to add a PHP package (like php-redis or something), I was running into errors that www-data did not have permissions to install.

I will definitely be revisiting this because its one of the bigger worries I had about this set up.

[szepeviktor]

Please be aware that www-data is a "system user" having higher privileges than normal users.
See UID-s in the top comment.

[szepeviktor]

then later on I want to add a PHP package

Setting user in a Docker image should be the last step.

I hope you do not intent to install packages in a running container!

[jaydrogers]

I hope you do not intent to install packages in a running container!

No, this would be like this...

Problem

• If I set a USER 12345 to run the serversideup/php:8.0-fpm-nginx as, how would down stream docker images add their project dependencies?

For example

(I think I tried this earlier)

On a downstream docker project, I might want a new Dockerfile that depends off of the base image from ServerSideUp:

FROM serversideup/php:8.0-fpm-nginx

RUN apt update && apt install php-redis

☝️ If I have USER 12345 (telling the container to run as UID 12345 from the parent image), this will fail because USER 12345 cannot install php-redis.

Thoughts?

[szepeviktor]

how would down stream docker images add their project dependencies?

USER 0
MANAGE DEPS
USER 12345

Done!

[jaydrogers]

I will definitely give this a whirl, thanks!!

[jaydrogers]

Here is an update on this:

Problem

• When I use S6 Overlay, I cannot get logging to work on the php-fpm image

How to recreate the problem

1. Copy my Dockerfile

####################################################
# Server Side Up -  PHP 7.4 / FPM image 
#####################################################

FROM serversideup/php:beta-7.4-cli

LABEL maintainer="Jay Rogers (@jaydrogers)"

# Set default PHP environment variables

ENV PHP_DATE_TIMEZONE="UTC" \
    PHP_DISPLAY_ERRORS=On \
    PHP_ERROR_REPORTING="E_ALL & ~E_DEPRECATED & ~E_STRICT" \
    PHP_MEMORY_LIMIT="256M" \
    PHP_MAX_EXECUTION_TIME="99" \
    PHP_POST_MAX_SIZE="100M" \
    PHP_UPLOAD_MAX_FILE_SIZE="100M" \
    PHP_POOL_NAME="www" \
    PHP_PM_CONTROL=dynamic \
    PHP_PM_MAX_CHILDREN="20" \
    PHP_PM_START_SERVERS="2" \
    PHP_PM_MIN_SPARE_SERVERS="1" \
    PHP_PM_MAX_SPARE_SERVERS="3"

# Install FPM
RUN apt-get update \
    && apt-get -y --no-install-recommends install \
        php7.4-fpm \
        && echo "Allow pool name to be set via env, default it to 'www'..." \
    && sed -i -e 's/\[www\]/\[$\{PHP_POOL_NAME\}]/g' /etc/php/7.4/fpm/pool.d/www.conf \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* /usr/share/doc/*

# Apply PHP configuration file
# COPY etc/php/fpm/pool.d/y-override-php-defaults.conf /etc/php/7.4/fpm/pool.d/y-override-php-defaults.conf

CMD ["/usr/sbin/php-fpm7.4", "-O" ]

# Open up fcgi port
EXPOSE 9000

2. Build my Dockerfile locally
Run this from the folder where you placed the Dockerfile:

docker build --pull . -t localhost/php:7.4-fpm

3. Run the local image
Run the

docker run -it --rm --name fpm localhost/php:7.4-fpm

Important note:

1. The Dockerfile above depends on the beta image (serversideup/php:beta-7.4-cli), which is built from this file https://github.com/serversideup/docker-php/blob/dev/php/7.4/cli/Dockerfile
2. The CLI image is based off of serversideup/docker-baseimage-s6-overlay-ubuntu:20.04, which is located in this new repo https://github.com/serversideup/docker-baseimage-s6-overlay-ubuntu/blob/main/Dockerfile

Things that concern me

I don't even know if this is possible to run as a "non-root" user due to how PHP-FPM is structured. I'm pretty sure PHP-FPM needs root in order to start its processes.

Other repos that are running PHP as "root"

These very talented groups are also not running things as an unprivileged user:

1. bitnami/php-fpm
2. linuxserver/docker-nextcloud (great example of a PHP app running on S6 Overlay... they aren't PHP-FPM though...)

What I think I might have to do

My gut feeling is telling be that I will:

• Need to continue to run the container as root
• Use the configurations of NGINX & PHP-FPM to select the proper user (my 9999 user)

Calling in help

@szepeviktor: Are you aware of any examples of projects running PHP as an unprivileged user?

[szepeviktor]

Hello! It is highly popular to give a sh*t about what is(is going on) inside a container.
People do not have time to follow CVE-s. So there's such a thing as breaking out of a container.

Actually it is a novice mistake to run something as root - no matter whether inside a container or not.

S6 Overlay needs to run as root but it does not mean that PHP-FPM needs too.
PHP-FPM opens a socket file and a TCP socket, starts threads, creates a PID file - what is the problem here?

[szepeviktor]

Are you aware of any examples of projects running PHP as an unprivileged user?

I think PHP-FPM operates this way

The master process runs as root, workers run as a normal user.

[jaydrogers]

Thanks for chiming in!

You confirmed my assumptions. I will need to remove the extra arguments on this line:

docker-php/php/7.4/cli/Dockerfile

Line 51 in 718f310

ENTRYPOINT ["/init", "/bin/execlineb", "-s0", "-c", "export HOME $WEBUSER_HOME s6-setuidgid webuser $@"]

If I leave those lines in there above, PHP-FPM will not be able to start correctly because its trying to start the master process as webuser (userid 9999).

Instead, I will have root start the masterprocess, which will then use the PHP-FPM config to start the children as webuser (userid 9999).

Does that sound like a good approach?

[szepeviktor]

BTW Debian uses https://github.com/krallin/tini

[szepeviktor]

Does that sound like a good approach?

At first glace yes.
Staring a lot at htop may tell you much more.

[szepeviktor]

php-fpm.conf could have daemonize = no
and I think PHP-FPM could run as non-privileged user if you don't set user and group in pool config.

[jaydrogers]

php-fpm.conf could have daemonize = no

Thanks! I have this set already.

and I think PHP-FPM could run as non-privileged user if you don't set user and group in pool config.

Interesting! I will play around with this. Thanks!!

[szepeviktor]

It is open-source. You can spend weeks with it!

[tsterker]

Sorry for digging this discussion up. It felt like the most fitting place to add my findings/thoughts.

I was looking into the topic of the default root user and was worried that laravel queue workers/schedulers could accidentally be started as root (i.e. when not using su webuser -c '...') and then write files as root. Such a container would also pose a security risk.

I realized that I could use the S6_CMD_ARG0 environment variable to enforce that all docker commands are run as webuser, e.g. by adding this line to my Dockerfile:

ENV S6_CMD_ARG0='s6-setuidgid webuser'

Now all docker commands run as webuser:

docker run --name=app --rm "<IMAGE>" whoami
# [...]
# webuser

Note that any commands executed against the running container would still be as root:

docker exec app whoami
# root

While this feels a bit... crude, I currently can't see how this could have any negative effects and it addresses my primary concern about starting docker containers with the root user.

@jaydrogers do you have any thoughts on this?

[jaydrogers]

Oh man, this looks extremely promising. This would simplify a lot and get rid of that ugly code I have in there for su webuser 🤣

Thanks a ton for posting this @tsterker!

I’m on vacation starting tomorrow through next week. I am going to loop back to this once I return 👍

[jaydrogers]

I just merged this PR to test this out on our beta images 😃

#180

[jaydrogers]

For cleanliness, I am going to close this discussion in favor of the active issue. I have a lot of work done in v3.0 on this, but still a few things to clean up.

Track this for the latest #179