request contact with devs

[gijoe460]

I have been working with the Alpine build for a bit. I am not sure how to communicate with the devs here or in forum when/if I find findings in Twistlock. Who should I email or how do I communicate here to make suggestions in the Alpine build.

Thanks

[wglambert]

If it's about CVE's we get issues on those quite frequently
See #286 (comment) docker-library/openjdk#161, docker-library/openjdk#112, #286, docker-library/drupal#84, docker-library/official-images#2740, docker-library/ruby#117, docker-library/ruby#94, docker-library/python#152, docker-library/php#242, docker-library/buildpack-deps#46, docker-library/openjdk#185.
And https://github.com/docker-library/faq#why-does-my-security-scanner-show-that-an-image-has-so-many-cves

A CVE doesn't imply having an actual vulnerability, and often is even a false positive (given how most distributions handle versioning/security updates in stable releases). If there are actionable items we can resolve, we're happy to do so (and do so actively). We update all Debian based images to include any updates in apt packages at least monthly (we regenerate the base images and then rebuild all dependent images).

[gijoe460]

HI wglambert,
The normal practice that i have seen is not to bring up CVEs in open forum. I completely agree with all of the data you have provided above. Twistlock, if you take a quick peek across the interwebs, is not a free scanner (extremely expensive to our organization), has an extremely low percentage of false positives, works directly with Alpine devs ( a problem child in the Docker world for many reasons), and does not suffer from many of the things you mention because of its aggressive update cycles with NIST and OS devs.

That being said, I have seen some dangling dependencies that are not being removed in your Alpine image after compile. It is a very impressive way to single dockerfile configure, compile, and deploy in the same Image, but Docker/Alpine unfortunately its not working as advertised; and would be an OBE issue if I could help switch you to a multi-stage build. During the APK del command it should remove all build-deps and sub-dependencies, but scans are showing it is not. By compiling in stage 1 and moving the compiled code to stage 2 and then installing run-deps you would effectively not take the dangling "*-dev" dependencies with. Also, the Image size would considerably shrink.

I would be happy to make you a report to show you what i am looking at. Also i would welcome the chance to help in switching to a multi-stage. Our organization is extreme thankful for the use of your Alpine Image.

[yosifkit]

some dangling dependencies that are not being removed in your Alpine image after compile

To which installed packages in which image are you referring? Here is the list from 12.1-alpine:

$ docker run -it --rm postgres:12.1-alpine bash
bash-5.0# apk info
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
musl
busybox
alpine-baselayout
alpine-keys
libcrypto1.1
libssl1.1
ca-certificates-cacert
libtls-standalone
ssl_client
zlib
apk-tools
scanelf
musl-utils
libc-utils
libgcc
libstdc++
ncurses-terminfo-base
ncurses-terminfo
ncurses-libs
libedit
libxml2
libgpg-error
libgcrypt
libxslt
libffi
llvm8-libs
libuuid
icu-libs
readline
bash
su-exec
tzdata
.postgresql-rundeps
bash-5.0# apk info | grep dev
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
bash-5.0# 

We only keep packages that are necessary; see this part for how they are automatically detected:

postgres/Dockerfile-alpine.template

Lines 120 to 133 in 0d0485c

	&& runDeps="$( \
	scanelf --needed --nobanner --format '%n#p' --recursive /usr/local \
	| tr ',' '\n' \
	| sort -u \
	| awk 'system("[ -e /usr/local/lib/" $1 " ]") == 0 { next } { print "so:" $1 }' \
	)" \
	&& apk add --no-cache --virtual .postgresql-rundeps \
	$runDeps \
	bash \
	su-exec \
	# tzdata is optional, but only adds around 1Mb to image size and is recommended by Django documentation:
	# https://docs.djangoproject.com/en/1.10/ref/databases/#optimizing-postgresql-s-configuration
	tzdata \
	&& apk del .fetch-deps .build-deps \

---

As far as moving to a multi-stage build; the answer is almost always no. See https://github.com/docker-library/faq/#multi-stage-builds. TLDR: docker build cache from any intermediate stage is never tagged. It will be available for deletion on build servers. Once deleted, the servers will, at some point, waste time building them again (for postgres, there are 6 alpine images across 7 architectures; this is not a small rebuild).

[gijoe460]

$ docker run -it alpine sh
/ # apk info
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
musl
busybox
alpine-baselayout
alpine-keys
libcrypto1.1
libssl1.1
ca-certificates-cacert
libtls-standalone
ssl_client
zlib
apk-tools
scanelf
musl-utils
libc-utils
/ # apk add bash su-exec tzdata
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.10/community/x86_64/APKINDEX.tar.gz
(1/7) Installing ncurses-terminfo-base (6.1_p20190518-r0)
(2/7) Installing ncurses-terminfo (6.1_p20190518-r0)
(3/7) Installing ncurses-libs (6.1_p20190518-r0)
(4/7) Installing readline (8.0.0-r0)
(5/7) Installing bash (5.0.0-r0)
Executing bash-5.0.0-r0.post-install
(6/7) Installing su-exec (0.2-r0)
(7/7) Installing tzdata (2019c-r0)
Executing busybox-1.30.1-r2.trigger
OK: 18 MiB in 21 packages
/ # apk info
musl
busybox
alpine-baselayout
alpine-keys
libcrypto1.1
libssl1.1
ca-certificates-cacert
libtls-standalone
ssl_client
zlib
apk-tools
scanelf
musl-utils
libc-utils
ncurses-terminfo-base
ncurses-terminfo
ncurses-libs
readline
bash
su-exec
tzdata

As you can see, an Alpine initial and adding your run-deps. That means the following packages [libgcc libstdc++ libedit libxml2 libgpg-error libgcrypt libxslt libffi llvm8-libs libuuid icu-libs]
are dangling as they are not properly removed by the && apk del .fetch-deps .build-deps \

I'm not really sure why. But, the dangling packages are causing issues, and of course, also increasing the size of the build.

When you say that you as a group don't want to create multistage builds...does that mean "builder" builds created in a single dockerfile as well?

Such as-

ROM node:10 AS ui-build
WORKDIR /usr/src/app
COPY WebApp/ ./WebApp/
RUN cd WebApp && npm install @angular/cli && npm install && npm run build

FROM node:10 AS server-build
WORKDIR /root/
COPY --from=ui-build /usr/src/app/WebApp/dist ./WebApp/dist
COPY package*.json ./
RUN npm install
COPY index.js .

EXPOSE 3070

ENTRYPOINT ["node"]
CMD ["index.js"]

Thoughts?

[yosifkit]

bash su-exec tzdata are not the only packages kept; see the runDeps lines that auto detect shared libraries and then are passed to apk that adds the packages that they belong to to the virtual.

$ docker run -it --rm alpine:3.10
... (all the dockerfile steps here: https://github.com/docker-library/postgres/blob/0d0485cb02e526f5a240b7740b46c35404aaf13f/12/alpine/Dockerfile#L24-L118)
/usr/src/postgresql # runDeps="$( \
> scanelf --needed --nobanner --format '%n#p' --recursive /usr/local \
> | tr ',' '\n' \
> | sort -u \
> | awk 'system("[ -e /usr/local/lib/" $1 " ]") == 0 { next } { print "so:" $1 }' \
> )"
/usr/src/postgresql # echo "$runDeps"
so:libLLVM-8.so
so:libc.musl-x86_64.so.1
so:libcrypto.so.1.1
so:libedit.so.0
so:libgcc_s.so.1
so:libicui18n.so.64
so:libicuuc.so.64
so:libssl.so.1.1
so:libstdc++.so.6
so:libuuid.so.1
so:libxml2.so.2
so:libxslt.so.1
so:libz.so.1

[yosifkit]

And yes, any Dockerfile with multiple FROM lines is a multi-stage build and heavily discouraged in official-images.

$ # and a little more info about how apk figures .so -> package:
/usr/src/postgresql # apk info -P $runDeps
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
llvm8-libs-8.0.0-r1 provides:
so:libLLVM-8.so=0

musl-1.1.22-r3 provides:
so:libc.musl-x86_64.so.1=1

libcrypto1.1-1.1.1d-r0 provides:
so:libcrypto.so.1.1=1.1

libedit-20190324.3.1-r0 provides:
so:libedit.so.0=0.0.60

libgcc-8.3.0-r0 provides:
so:libgcc_s.so.1=1

icu-libs-64.2-r0 provides:
so:libicudata.so.64=64.2
so:libicui18n.so.64=64.2
so:libicuio.so.64=64.2
so:libicutest.so.64=64.2
so:libicutu.so.64=64.2
so:libicuuc.so.64=64.2

icu-libs-64.2-r0 provides:
so:libicudata.so.64=64.2
so:libicui18n.so.64=64.2
so:libicuio.so.64=64.2
so:libicutest.so.64=64.2
so:libicutu.so.64=64.2
so:libicuuc.so.64=64.2

libssl1.1-1.1.1d-r0 provides:
so:libssl.so.1.1=1.1

libstdc++-8.3.0-r0 provides:
so:libstdc++.so.6=6.0.25

libuuid-2.33.2-r0 provides:
so:libuuid.so.1=1.3.0

libxml2-2.9.9-r2 provides:
so:libxml2.so.2=2.9.9

libxslt-1.1.33-r2 provides:
so:libexslt.so.0=0.8.20
so:libxslt.so.1=1.1.33
cmd:xsltproc

zlib-1.2.11-r1 provides:
so:libz.so.1=1.2.11

[tianon]

See also:

$ docker pull postgres:alpine
alpine: Pulling from library/postgres
Digest: sha256:3a1217522e1da37f28a94bbb02eebe3ced4c28131da14799b710814cb959c6df
Status: Image is up to date for postgres:alpine
docker.io/library/postgres:alpine

$ docker run -it --rm postgres:alpine sh
/ # apk del --no-network .postgresql-rundeps
WARNING: Ignoring APKINDEX.00740ba1.tar.gz: No such file or directory
WARNING: Ignoring APKINDEX.d8b2a6f4.tar.gz: No such file or directory
(1/19) Purging .postgresql-rundeps (20191128.173728)
(2/19) Purging bash (5.0.0-r0)
Executing bash-5.0.0-r0.pre-deinstall
(3/19) Purging su-exec (0.2-r0)
(4/19) Purging tzdata (2019c-r0)
(5/19) Purging icu-libs (64.2-r0)
(6/19) Purging llvm8-libs (8.0.0-r1)
(7/19) Purging libstdc++ (8.3.0-r0)
(8/19) Purging libgcc (8.3.0-r0)
(9/19) Purging readline (8.0.0-r0)
(10/19) Purging libedit (20190324.3.1-r0)
(11/19) Purging ncurses-libs (6.1_p20190518-r0)
(12/19) Purging ncurses-terminfo (6.1_p20190518-r0)
(13/19) Purging ncurses-terminfo-base (6.1_p20190518-r0)
(14/19) Purging libxslt (1.1.33-r2)
(15/19) Purging libxml2 (2.9.9-r2)
(16/19) Purging libgcrypt (1.8.5-r0)
(17/19) Purging libgpg-error (1.36-r2)
(18/19) Purging libffi (3.2.1-r6)
(19/19) Purging libuuid (2.33.2-r0)
Executing busybox-1.30.1-r2.trigger
OK: 6 MiB in 14 packages
/ # postgres --help
Error loading shared library libxml2.so.2: No such file or directory (needed by /usr/local/bin/postgres)
Error loading shared library libicui18n.so.64: No such file or directory (needed by /usr/local/bin/postgres)
Error loading shared library libicuuc.so.64: No such file or directory (needed by /usr/local/bin/postgres)
Error relocating /usr/local/bin/postgres: xmlCharInRange: symbol not found
Error relocating /usr/local/bin/postgres: uloc_toLanguageTag_64: symbol not found
Error relocating /usr/local/bin/postgres: ucol_getVersion_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathRegisterNs: symbol not found
Error relocating /usr/local/bin/postgres: ucol_strcollUTF8_64: symbol not found
Error relocating /usr/local/bin/postgres: u_versionToString_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlFreeTextWriter: symbol not found
Error relocating /usr/local/bin/postgres: xmlStrchr: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCompiledEval: symbol not found
Error relocating /usr/local/bin/postgres: xmlStrstr: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCastBooleanToNumber: symbol not found
Error relocating /usr/local/bin/postgres: uloc_getDisplayName_64: symbol not found
Error relocating /usr/local/bin/postgres: uiter_setUTF8_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlStrcmp: symbol not found
Error relocating /usr/local/bin/postgres: xmlBufferFree: symbol not found
Error relocating /usr/local/bin/postgres: xmlBufferContent: symbol not found
Error relocating /usr/local/bin/postgres: xmlNewDoc: symbol not found
Error relocating /usr/local/bin/postgres: u_isprint_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathFreeContext: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCompile: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCastNodeSetToString: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterWriteBase64: symbol not found
Error relocating /usr/local/bin/postgres: ucol_open_64: symbol not found
Error relocating /usr/local/bin/postgres: ucol_close_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlCtxtReadDoc: symbol not found
Error relocating /usr/local/bin/postgres: u_tolower_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlCopyNode: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterWriteBinHex: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterStartElement: symbol not found
Error relocating /usr/local/bin/postgres: xmlGetUTF8Char: symbol not found
Error relocating /usr/local/bin/postgres: xmlBufferLength: symbol not found
Error relocating /usr/local/bin/postgres: xmlCtxtReadMemory: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCastNodeToString: symbol not found
Error relocating /usr/local/bin/postgres: xmlParseBalancedChunkMemory: symbol not found
Error relocating /usr/local/bin/postgres: xmlSetExternalEntityLoader: symbol not found
Error relocating /usr/local/bin/postgres: xmlParserPrintFileContext: symbol not found
Error relocating /usr/local/bin/postgres: u_isalnum_64: symbol not found
Error relocating /usr/local/bin/postgres: ucol_nextSortKeyPart_64: symbol not found
Error relocating /usr/local/bin/postgres: u_toupper_64: symbol not found
Error relocating /usr/local/bin/postgres: u_strToTitle_64: symbol not found
Error relocating /usr/local/bin/postgres: u_isalpha_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathNewContext: symbol not found
Error relocating /usr/local/bin/postgres: ucol_strcoll_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlNodeDump: symbol not found
Error relocating /usr/local/bin/postgres: u_isspace_64: symbol not found
Error relocating /usr/local/bin/postgres: ucnv_open_64: symbol not found
Error relocating /usr/local/bin/postgres: uloc_countAvailable_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterWriteRaw: symbol not found
Error relocating /usr/local/bin/postgres: uloc_getAvailable_64: symbol not found
Error relocating /usr/local/bin/postgres: u_islower_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathFreeObject: symbol not found
Error relocating /usr/local/bin/postgres: u_isdigit_64: symbol not found
Error relocating /usr/local/bin/postgres: u_ispunct_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlGetExternalEntityLoader: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterEndElement: symbol not found
Error relocating /usr/local/bin/postgres: xmlTextWriterWriteAttribute: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCastBooleanToString: symbol not found
Error relocating /usr/local/bin/postgres: xmlSetGenericErrorFunc: symbol not found
Error relocating /usr/local/bin/postgres: xmlFreeParserCtxt: symbol not found
Error relocating /usr/local/bin/postgres: xmlNewParserCtxt: symbol not found
Error relocating /usr/local/bin/postgres: ucnv_fromUChars_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlStrncmp: symbol not found
Error relocating /usr/local/bin/postgres: u_isgraph_64: symbol not found
Error relocating /usr/local/bin/postgres: ucol_getSortKey_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlSetStructuredErrorFunc: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathFreeCompExpr: symbol not found
Error relocating /usr/local/bin/postgres: xmlXPathCastNumberToString: symbol not found
Error relocating /usr/local/bin/postgres: xmlInitParser: symbol not found
Error relocating /usr/local/bin/postgres: xmlNewTextWriterMemory: symbol not found
Error relocating /usr/local/bin/postgres: ucnv_toUChars_64: symbol not found
Error relocating /usr/local/bin/postgres: u_isupper_64: symbol not found
Error relocating /usr/local/bin/postgres: u_errorName_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlBufferCreate: symbol not found
Error relocating /usr/local/bin/postgres: xmlCheckVersion: symbol not found
Error relocating /usr/local/bin/postgres: xmlNewStringInputStream: symbol not found
Error relocating /usr/local/bin/postgres: xmlStrdup: symbol not found
Error relocating /usr/local/bin/postgres: xmlFreeNode: symbol not found
Error relocating /usr/local/bin/postgres: u_strToUpper_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlFreeDoc: symbol not found
Error relocating /usr/local/bin/postgres: u_strToLower_64: symbol not found
Error relocating /usr/local/bin/postgres: xmlIsExtenderGroup: symbol not found
Error relocating /usr/local/bin/postgres: xmlIsDigitGroup: symbol not found
Error relocating /usr/local/bin/postgres: xmlIsCombiningGroup: symbol not found
Error relocating /usr/local/bin/postgres: xmlIsBaseCharGroup: symbol not found
Error relocating /usr/local/bin/postgres: xmlGenericError: symbol not found
Error relocating /usr/local/bin/postgres: xmlStructuredErrorContext: symbol not found
Error relocating /usr/local/bin/postgres: xmlFree: symbol not found
Error relocating /usr/local/bin/postgres: xmlGenericErrorContext: symbol not found
Error relocating /usr/local/bin/postgres: xmlStructuredError: symbol not found

[gijoe460]

This is where I am starting to exceed my knowledge...but is it possible to extract those library files *.so and remove the package they are a part of? can Postgres use the libraries if the package they are contained in is no longer there? Is it simply a folder where all of the libraries are and Postgres is pointed to? Or, does the application actually access that package to reach the library contained within.

I ask because if/when i find vulnerabilities i "have" to remove them. But, you have shown me (thank you for educating btw) that i have to have those libraries for Postgres to work. How would we isolated the CVE in the package from the fact that the application needs the libraries?

Thank you for the help.

[yosifkit]

How would we isolated the CVE in the package from the fact that the application needs the libraries?

The package is just the metadata to install (and update) the .so file or multiple .so files and other related files (like configuration and docs). You can see the list of files a package will install on pkgs.alpinelinux.org (see the "Contents of package" link at the bottom of page, like the libgccon Alpine 3.10 for x86_64). The shared library files could be moved to a different location and postgres could use them fine, but removing the package and not the .so files will not remove the "vulnerability" (and should still be found by your scanner).

As noted above "a CVE doesn't imply having an actual vulnerability", but also, security teams (like the ones at Debian, Ubuntu, or RedHat) have to balance security fixes with stability (they often support older versions than upstreams do to provide stable long term releases) and mark CVE's as "minor" or "won't fix" in some releases of their distribution (see #286 (comment) for a few examples).

Note: I do not know the inner workings of how these teams decide which CVE's get fixes applied on which OS release channel, but I trust that they do they best they can to fix important vulnerabilities without overwhelming their resources. See also https://www.debian.org/security/.

If there are vulnerabilities that are fixed in multiple distributions, but not in Alpine Linux, then that would be up to the Alpine maintainers to evaluate applying a fix (http://bugs.alpinelinux.org/).

[gijoe460]

With your example, I think we are close to figuring out a solution that might work for me, is it possible to discuss more? off of this open channel?
That way i can talk about a particular package?

[wglambert]

Closing since this isn't an issue with the image but a question on quieting CVE alerts

is it possible to extract those library files *.so and remove the package they are a part of?
I ask because if/when i find vulnerabilities i "have" to remove them.

You should try asking over at the Docker Community Forums, Docker Community Slack, or Stack Overflow. Since these repos aren't really a user-help forum

[gijoe460]

wglambert,
This is an issue with the image. If you are building CVEs (vulnerabilities into it). By quieting, I mean you scanning and keeping libraries up to date.

Talking to a community that you mentioned is not going to help with libraries you are choosing to use. Please take the time to actually understand the question.