chore: rebuild sinker to address jan-2024 glibc updates for debian bookworm

[eumoh1601]

related to: https://github.com/influxdata/tubernetes/issues/1567

changes:

rebuild sinker to address jan-2024 glibc updates for debian bookworm

#Remove setuid/setgid bits from executables. Also If the path is /proc, don't descend into it. This effectively excludes /proc from the search.
RUN find / -path /proc -prune -o -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

oops

[marcdavoli]

Can you elaborate a little bit on why these changes are necessary?

[jdstrand]

As I read this, the groupadd is simply moved to be closer to the useradd, which is fine.

The part about removing setuid/setgid executables is from https://github.com/influxdata/tubernetes/issues/1567 and the idea is that if we're going to use a base image like Debian or Ubuntu, then stripping out the setuid/setgid bits off everything in the container is a meaningful hardening measure for containers running as non-root (like sinker does and like (by far nearly) all containers should!) since vulnerabilities in libraries/etc that the setuid executable uses could allow an attacker with code exec within the container to escalate to root within the container. Since containers are not considered root strong, this could allow an attacker to escalate to root on the pod and break out of the container. Stripping out the setuid/setgid bits at container build time blocks this avenue of attack within the container.

That said, the addition of -path /proc -prune causes nothing to match. I suspect you did this to avoid the error output. You might be able to do this instead if using bash:

# Remove setuid/setgid bits from executables as a hardening measure so non-root processes can't escalate.
RUN find $(ls -d /!(dev|proc|sys)) -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

Otherwise, I think you'd want to change this to:

# Remove setuid/setgid bits from executables as a hardening measure so non-root processes can't escalate.
RUN find /*bin /lib* /opt /usr -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

This doesn't catch all directories, but it does catch all the places that setuid/setgid binaries could be installed by distro packages.

Please also remove this (now unneeded) comment:

# RUN apt update \
#     && apt install --yes ca-certificates libssl3 --no-install-recommends \
#     && rm -rf /var/lib/{apt,dpkg,cache,log} \
#     && groupadd --gid 1500 sinker \
#     && useradd --uid 1500 --gid sinker --shell /bin/bash --create-home sinker

[jdstrand]

That said, the addition of -path /proc -prune causes nothing to match.

CORRECTION: I did something wrong when I tested this. I can see now that find / -path /proc -prune -o -type f \( -perm -4000 -o -perm -2000 \) -ls does match stuff. This might be a refinement you'd still be interested in though:

# Remove setuid/setgid bits from executables as a hardening measure so non-root processes can't escalate.
RUN find / \( -path /dev -o -path /proc -o -path /sys \) -prune -o -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

[eumoh1601]

Updated the newly created image tested in k8s pods using tilt. Sinker pods seems to be running as usual.

[marcdavoli]

As discussed, let's get Jamie to take a look before we merge.

[jdstrand]

As I read this, the groupadd is simply moved to be closer to the useradd, which is fine.

The part about removing setuid/setgid executables is from https://github.com/influxdata/tubernetes/issues/1567 and the idea is that if we're going to use a base image like Debian or Ubuntu, then stripping out the setuid/setgid bits off everything in the container is a meaningful hardening measure for containers running as non-root (like sinker does and like (by far nearly) all containers should!) since vulnerabilities in libraries/etc that the setuid executable uses could allow an attacker with code exec within the container to escalate to root within the container. Since containers are not considered root strong, this could allow an attacker to escalate to root on the pod and break out of the container. Stripping out the setuid/setgid bits at container build time blocks this avenue of attack within the container.

That said, the addition of -path /proc -prune causes nothing to match. I suspect you did this to avoid the error output. You might be able to do this instead if using bash:

# Remove setuid/setgid bits from executables as a hardening measure so non-root processes can't escalate.
RUN find $(ls -d /!(dev|proc|sys)) -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

Otherwise, I think you'd want to change this to:

# Remove setuid/setgid bits from executables as a hardening measure so non-root processes can't escalate.
RUN find /*bin /lib* /opt /usr -type f \( -perm -4000 -o -perm -2000 \) -exec chmod a-s {} \;

This doesn't catch all directories, but it does catch all the places that setuid/setgid binaries could be installed by distro packages.

Please also remove this (now unneeded) comment:

# RUN apt update \
#     && apt install --yes ca-certificates libssl3 --no-install-recommends \
#     && rm -rf /var/lib/{apt,dpkg,cache,log} \
#     && groupadd --gid 1500 sinker \
#     && useradd --uid 1500 --gid sinker --shell /bin/bash --create-home sinker

[jdstrand]

I'm going to approve as is (now that I corrected myself), but please consider the couple things I mentioned.

[jdstrand]

@eumoh1601 thanks for working on this! :)