Support for arbitrary user

[fsteccanella]

By default, OpenShift Container Platform runs containers using an arbitrarily assigned user ID. This provides additional security against processes escaping the container due to a container engine vulnerability and thereby achieving escalated permissions on the host node.

For an image to support running as an arbitrary user, directories and files that may be written to by processes in the image should be owned by the root group and be read/writable by that group. Files to be executed should also have group execute permissions.

Because the container user is always a member of the root group, the container user can read and write these files. The root group does not have any special permissions (unlike the root user) so there are no security concerns with this arrangement.

(https://docs.redhat.com/en/documentation/openshift_container_platform/3.10/html/creating_images/creating-images-guidelines#openshift-specific-guidelines)

This pull request adds support for running Caddy as an arbitrary user:

chgrp -R 0 /config && chmod -R g=u /config;
chgrp -R 0 /data && chmod -R g=u /data;
chgrp -R 0 /etc/caddy && chmod -R g=u /etc/caddy;
chgrp -R 0 /usr/share/caddy && chmod -R g=u /usr/share/caddy;
chgrp -R 0 /usr/bin/caddy && chmod -R g=u /usr/bin/caddy;

[fsteccanella]

hi, are there any issue that block this pr?
i would love to see it merged on upstream...

[polarathene]

TL;DR:

• Only caddy executable needs user + group correction, adjust line to: tar -xz -f /tmp/caddy.tar.gz -C /usr/bin caddy && chown 0:0 /usr/bin/caddy; \
• You can use a single line change for copying user perms to group: chmod -R g=u /config /data /etc/caddy /usr/share/caddy /usr/bin/caddy

Queries:

• Unclear why all these need to be writable by the root group (makes little sense for /usr/bin/caddy)
• Volume mounts to any of these locations will undo the change, user will need to ensure they apply the chmod + chown for the intended functionality to work.
• New files written will still use the umask, thus adopt default perms like 755, granting write only to the file owner, not the group which may cause some issues?
• Can you cite other official images that have adopted the practice proposed here?

---

Does OpenShift not have the equivalent of rootless that both Podman and Docker offer? That leverages user namespaces with the host /etc/subuid + /etc/subgid to run the internal container root user as a non-root user on the host.

Can you reference other popular official images that have adopted this practice you're proposing here?

---

It seems the bulk of the chgrp changes you're proposing are redundant?

$ podman run --rm -it caddy ash
$ apk add eza

# This is just a fancier `ls -l` command:
$ eza -lanhog --tree --no-time --no-filesize \
  /config /data /etc/caddy /usr/share/caddy /usr/bin/caddy

Octal Permissions User Group Name
0755  drwxr-xr-x@ 0    0     /etc/caddy
0644  .rw-r--r--@ 0    0     └── Caddyfile
0755  drwxr-xr-x@ 0    0     /usr/share/caddy
0644  .rw-r--r--@ 0    0     └── index.html
0755  .rwxr-xr-x@ 1001 127   /usr/bin/caddy
0755  drwxr-xr-x@ 0    0     /config
0755  drwxr-xr-x@ 0    0     └── caddy
0755  drwxr-xr-x@ 0    0     /data
0755  drwxr-xr-x@ 0    0     └── caddy

Colour screenshot if it is easier to read:

So only /usr/bin/caddy has an undesirable user and group assigned, 1001:127 is standard when built from Github Actions CI, an easy fix is to modify this line:

caddy-docker/Dockerfile.tmpl

Line 35 in eb4bf9a

tar x -z -f /tmp/caddy.tar.gz -C /usr/bin caddy; \

With either of these approaches:

# Extracts to stdout and writes output to /usr/bin/caddy, with default ownership and permissions:
# NOTE: Must restore executable bit with chmod
tar -xzO -f /tmp/caddy.tar.gz caddy > /usr/bin/caddy && chmod +x /usr/bin/caddy; \

# Alternatively, adjust ownership directly after (retains other file metadata from archive):
tar -xz -f /tmp/caddy.tar.gz -C /usr/bin caddy && chown 0:0 /usr/bin/caddy; \

That leaves your change to copy the user permissions into group permissions which can be done with a single line:

chmod -R g=u /config /data /etc/caddy /usr/share/caddy /usr/bin/caddy

Any bind mount volumes to these locations would need to ensure they have the equivalent root group ownership with write permissions. Assigning SGID (g+s) to directories upon creation can also work to ensure newly created files are created with the directory group instead of the users group.

Although depending on what you're doing I don't think all these locations need write permission granted? Why would /usr/bin/caddy need +w?

---

The root group does not have any special permissions (unlike the root user) so there are no security concerns with this arrangement.

Are you referring to capabilities? You could drop those with --cap-drop all to get the same benefit?

Typically to exploit a vulnerability for the container root user to wreck havoc on the host as root it requires actively reducing security on the container (granting more capabilities/privilege, access to the docker socket or equivalent, etc). This doesn't necessarily require the container user to be root to gain access to root on the host either.