One reason to consider switching back to ubuntu base images
#2918
Comments
|
Do you know which sha/hash (not quite sure what to call it) of the base image ( I don't know how image caching in GH Actions works. Is it shared between our builds, what is available on the node our job runs, no sharing at all? Hence the idea of looking at the SHA that is being used and comparing it to the latest available one (compared to when the hub image was built). |
I've tested with the absolute latest images using So my conclusion atm is that |
Update@tianon provided a great comment in docker-library/python#708 (comment) about how trivy and other container scanners pick up or treat declared intent by ubuntu compared to debian.
Case exampleI looked into Still, both Expand me to see bash script used as practical testecho
echo "------------------------------------------------------------------------"
echo "This script investigates if CVE-2005-2541 is addressed differently"
echo "between debian:11 and ubuntu:22.04, as that helps when considering when"
echo "container scanners report it to be fixed in ubuntu but not fixed in"
echo "debian."
echo
echo "ref: https://www.cvedetails.com/cve/CVE-2005-2541/"
echo "ref: https://security-tracker.debian.org/tracker/CVE-2005-2541"
echo
echo "\$ tar --help | grep -A2 -- --preserve-permissions"
echo
echo " -p, --preserve-permissions, --same-permissions"
echo " extract information about file permissions"
echo " (default for superuser)"
echo "------------------------------------------------------------------------"
echo
echo
echo
# go to a safe location
mkdir -p /tmp/docker-mounted-dir
cd /tmp/docker-mounted-dir
# dump test script to be run in containers
cat <<EOT > test
cd /tmp
# setup
mkdir -p tarme
touch tarme/setuid-file
chmod u+s tarme/setuid-file
tar -cf archive.tar tarme
rm -rf tarme
# test
echo "ls -l after unpacking with/without -p flag"
tar -pxf archive.tar tarme
ls -l tarme/setuid-file
rm -rf tarme
tar -xf archive.tar tarme
ls -l tarme/setuid-file
rm -rf tarme
# cleanup
rm -rf tarme
rm archive.tar
EOT
echo "----------------------------"
echo "tar -pxf and tar -xf as root"
echo "----------------------------"
echo
echo "debian:11"
docker run -it --rm -v $(pwd):$(pwd) debian:11 bash $(pwd)/test
echo
echo "ubuntu:22.04"
docker run -it --rm -v $(pwd):$(pwd) ubuntu:22.04 bash $(pwd)/test
echo
echo "------------------------------"
echo "tar -pxf and tar -xf as nobody"
echo "------------------------------"
echo
echo "debian:11"
docker run -it --rm -v $(pwd):$(pwd) --user=nobody debian:11 bash $(pwd)/test
echo
echo "ubuntu:22.04"
docker run -it --rm -v $(pwd):$(pwd) --user=nobody ubuntu:22.04 bash $(pwd)/test
echoConclusionThis seems to be a I'd very much like to resolve this upstream or at least have a reference to an upstream disucssion about resolving it before working around it by switching to ubuntu. |
|
I think https://github.com/aquasecurity/trivy-db (EDIT: no probably https://github.com/aquasecurity/vuln-list) may be a place to create an issue. I could not find an issue there about it. I saw a trace about Using {
"VulnerabilityID": "CVE-2005-2541",
"PkgName": "tar",
"InstalledVersion": "1.34+dfsg-1",
"Layer": {
"Digest": "sha256:17c9e6141fdb3387e5a1c07d4f9b6a05ac1498e96029fa3ea55470d4504f7770",
"DiffID": "sha256:d9d07d703dd5ba0b8e23bf7e1bd9f7e4093418a58dc9e470ca013d1c3a1b5bb5"
},
"SeveritySource": "nvd",
"PrimaryURL": "https://avd.aquasec.com/nvd/cve-2005-2541",
"Title": "tar: does not properly warn the user when extracting setuid or setgid files",
"Description": "Tar 1.15.1 does not properly warn the user when extracting setuid or setgid files, which may allow local users or remote attackers to gain privileges.",
"Severity": "HIGH",
"CVSS": {
"nvd": {
"V2Vector": "AV:N/AC:L/Au:N/C:C/I:C/A:C",
"V2Score": 10
},
"redhat": {
"V3Vector": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
"V3Score": 7
}
},
"References": [
"http://marc.info/?l=bugtraq\u0026m=112327628230258\u0026w=2",
"https://lists.apache.org/thread.html/rc713534b10f9daeee2e0990239fa407e2118e4aa9e88a7041177497c@%3Cissues.guacamole.apache.org%3E"
],
"PublishedDate": "2005-08-10T04:00:00Z",
"LastModifiedDate": "2021-06-18T15:15:00Z"
}Aqua security's website lists it as 0/10 score issue for Ubuntu, but don't mention Debian: https://avd.aquasec.com/nvd/2005/cve-2005-2541/ Debian doesn't note https://security-tracker.debian.org/tracker/CVE-2005-2541 to be Overall, I can't conclude clearly what could be done or what makes sense to do =/ |
|
Looking at https://github.com/aquasecurity/vuln-list#source, it seems the issue is that trivy has a source from ubuntu that omits CVE-2005-2541, while it has a source from debian that includes it. Hmmm... Debian: https://security-tracker.debian.org/tracker/CVE-2005-2541 Looking at another newer CVE, it seems that ubuntu reporting it as "needs triage" makes it not show up for ubuntu users while it does for debian who concludes them to be vulnerable. https://ubuntu.com/security/CVE-2021-46848 Opinion evolutionIt seems that Maybe artifacthub.io etc could convey more strongly a score related to what is fixable, and not judge too harshly by what is not fixable? Arrrgh such a tricky topic.
|
|
My view on this:
We could add something along these lines to our docs if we agree a policy? |
|
Thanks a lot for doing so much digging Erik!! I learnt a lot! I think I agree with the idea to not switch and maybe to add a note to the docs explaining the reasoning. It seems like this knowledge about how to interpret/ignore the results of automated scanners is not widespread and pretty subtle. After all it took you a while to find all the info. And then investing our human effort in to making sure we always use the latest build of the base image, and other things that increase user's security instead of chasing the numbers based on what a robot says. It would be nice if there was a better signal to noise ratio but as long as it is like this it seems the best thing to do is not pay too much attention to it and keep an eye out for legit CVEs and getting the patches into the images repo2docker builds. |
|
I'll go for a close here as I conclude no action at this point, thinking that for now that we stick with debian based images. Thanks for brainstorming about this everyone!! |
|
Oh, wait, regarding a policy.
If we have a policy, I figure it should be as an inline comment only in the Dockerfile. That is where people may look and consider adding patches so its better its written there directly. I'd support a policy that doesn't add to what we currently do, because I think what we do is sufficient.
|
Update
Security vulnerabilities reported in
debianbased images doesn't seem less safe thanubuntu. They both have security overviews, and the key difference is how security scanners liketrivyinterpret these. See #2918 (comment)Original topic
The
hubpod's base image is as of #2733python:3.9-slim-bullseye, which is based ondebian:bullseye-slim. Previously we were based onubuntu.I've observed that
debian:bullseye-slimseem to come with a lot of unfixed known vulnerabilities, whileubuntu:22.04don't. That makes me consider if we should go forubuntu:22.04+ installing python ourselves again. I think maybe that isn't well enough motivated by this yet though, but if there are other reasons coming up, maybe we should go back toubuntu.Related
The text was updated successfully, but these errors were encountered: