snw35 / cloudenv Goto Github PK

Hi,
I just ran a snyk test against that latest version of the container, and it reported a couple vulns. I'm fairly certain the musl vulnerability is a false-positive, but might want to update the jq package to address.

Thanks.

-Dave

dviebrock@FVFX62JZHV2D gitlab-eks-cluster % snyk container test snw35/cloudenv:latest
Testing snw35/cloudenv:latest...
✗ Medium severity vulnerability found in musl/musl-utils
Description: Out-of-bounds Write
Info: https://snyk.io/vuln/SNYK-ALPINE313-MUSL-1067865
Introduced through: musl/[email protected], libc-dev/[email protected], meta-common-packages@meta
From: musl/[email protected]
From: libc-dev/[email protected] > musl/[email protected]
From: meta-common-packages@meta > musl/[email protected]
Fixed in: 1.2.2_pre2-r0
✗ High severity vulnerability found in jq/jq
Description: Out-of-Bounds
Info: https://snyk.io/vuln/SNYK-ALPINE313-JQ-1067448
Introduced through: jq/[email protected]
From: jq/[email protected]
Image layer: '/bin/sh -c apk --update --no-cache upgrade -a && apk --update --no-cache add bash bash-completion bind-tools ca-certificates coreutils curl diffutils fish fzf fzf-bash-completion git gnupg groff iputils jq keychain libusb ncurses net-tools nmap openssh-client openssl perl py3-pip python3 shadow su-exec tmux tzdata && pip install --upgrade pip && pip install --no-cache-dir cookiecutter datadog okta-awscli wheel && curl -o /usr/local/bin/ecs-cli https://s3.amazonaws.com/amazon-ecs-cli/ecs-cli-linux-amd64-latest && chmod +x /usr/local/bin/ecs-cli && sed -i 's/^CREATE_MAIL_SPOOL=yes/CREATE_MAIL_SPOOL=no/' /etc/default/useradd && mkdir -p /etc/bash_completion.d && ln -s /usr/bin/python3 /usr/bin/python'
Fixed in: 1.6_rc1-r0
Organization: dave.viebrock
Package manager: apk
Project name: docker-image|snw35/cloudenv
Docker image: snw35/cloudenv:latest
Platform: linux/amd64
Licenses: enabled
Tested 141 dependencies for known issues, found 2 issues.

I installed this on a Mac and on first run, got this error (in docker container logs)

No matching internal group found, creating one...
groupadd: GID '20' already exists

It looks like the check to see if the group exists, in https://github.com/snw35/cloudenv/blob/master/docker-entrypoint.sh#L70 is not working as intended.

Looking into the image we have,

bash-5.1# cat /etc/group | grep 20
dialout:x:20:root
nofiles:x:200:
smmsp:x:209:smmsp

There is a group called dialout that has the id 20 assigned. That appears to be clashing with my current HOST_GROUP_ID which is also 20. The code in docker-entrypoint.sh to detect this scenario is not working as far as I can tell, because it is falling into the flow as if there was no conflict.

I was able to work around this issue by hacking the cloudenv script (locally) to pass in an empty value into the HOST_GROUP_ID and that worked. However, I am not sure what the right fix is because it is unclear what the original use-case may have been for the "use existing group if it matches" scenario. @snw35 any advice?

Entry script fails if user does not have a local group name

i.e. if id -g -n outputs a numeric value

When running on a mac, usermod chews CPU and never exits.

Suspect issue caused by large UID (327472772)

Looks like we went from terraform 0.15.0 -> 0.11.15???

this commit here?
c848257

Due to hardcoded paths in some configs, the container should use the same path to a user's home, such as /Users/user or /home/user.

To reproduce,

• Host (laptop) with agent forwarding enabled
• SSH to remote host
  • Test ssh -v [email protected] and see it succeeds using keys forwarded from the laptop
  • Install cloudenv on this same remote host
  • Run cloudenv
    • Test ssh -v [email protected] and see it fails

Inside cloud env, SSH_AUTH_SOCK is not mounted and pointing to the host sock as expected.