4 ms·

> don't routine security updates mean you're constantly rebuilding and redeploying these images? It means you should be constantly rebuilding and redeploying t

by nh2 8y ago

> don't routine security updates mean you're constantly rebuilding and redeploying these images? It means you should be constantly rebuilding and redeploying these images. The fewest people I've seen use Docker actually do that. The answer I've heard most commonly so far is "uh hmm ... right, given that I see new CVEs fixed every day, scrolling by in the `apt-get dist-upgrade` I do daily on my desktop, we should probably be doing that for our Docker as well ..." Many then refer to per-push CI/CD, not realising that holes need to be fixed regularly and not when you push. The fewest have automation set up that rebuilds and redeploys when the upstream docker image changes. Plain Debian/Ubuntu servers have the benefit of `unattended-upgrades`, but with Docker you have to take on that task yourself and build automation for it. Also have a look at https://hub.docker.com/r/library/ubuntu/tags/ https://hub.docker.com/r/library/ubuntu/tags/ At the time of writing, every single image is labelled with "This image has vulnerabilities".

jes5199 8y ago
who has an app that they don’t deploy daily?
- kawsper 8y ago
  Many - and our deploys on weekends are almost zero.
- majewsky 8y ago
  I highly doubt that anyone would deploy everything daily. Your own code, maybe. But what about dependencies? Do you upgrade your Postgres container daily?
- barrkel 8y ago
  Some of us have contractual obligations not to deploy during the week, and require us to notify and receive permission from our customers for out of band deployments.
jrs95 8y ago
You probably shouldn’t be using Ubuntu base images anyways. The closer you can get to “scratch” the better, and the fewer security related issues you’ll have. For most use cases I think Alpine is a much better base image.
- de_watcher 8y ago
  That's more about trust and faith in the maintainers of the distribution (that they won't screw up).
  - alexandre_m 8y ago
    It's about having the minimal number of system packages and libraries that your app actually needs. Alpine is leaner so attack surface is thinner.
  - erik_seaberg 8y ago
    This. If you start adding stuff to "FROM scratch", you are creating your own obscure Linux distro. When you screw up, there are no other customers to report bugs to you, much less other maintainers to help.
    - jrs95 8y ago
      You really shouldn't be adding stuff to "FROM scratch" unless you have one statically linked binary and maybe some config files or something like that. If you actually need packages, you should use something like Alpine if possible.
TheDong 8y ago
> At the time of writing, every single image is labelled with "This image has vulnerabilities". The majority of those are not applicable in any way to your average container. I would highly encourage you to not attempt to make points off such bad data. See below for why I think it's bad data. I'd also like to point out that those CVEs are even more of a pointless thing to make such a point with since almost all of them aren't fixed in upstream ubuntu... which is to say an ubuntu server with 'unattended upgrades' would be just as 'vulnerable' as these docker containers, except moreso because more of them would actually be relevant in such an environment. Your overall point is valid, but your reference to those 'vulnerabilities' is egregiously misleading. Let me analyse as a human all the so-called "critical vulnerabilities" listed there for Xenial: 1. glibc 2.23-0ubuntu10 - CVE-2018-6485 This is exploited by C code which intentionally calls posix_memalign or aligned_alloc (instead of malloc) with unusually large arguments. There are very few codebases out there which make use of that in the first place. If your container is not running untrusted code which links against libc, you have little to fear. This CVE will not impact the average container running some ruby or nodejs application. Ubuntu also offers no update yet, so it's not actionable. 2. ncurses 6.0+20160213-1ubuntu1 - CVE-2017-10684, CVE-2017-10685 Only affects you if you're piping un-sanitized user input into an ncurses application which then displays it. I doubt there are many, if any, server applications that do this. Also not actionable. 3. shadow 4.2-3.1ubuntu5.3 - CVE-2017-12424 I'm sure there are plenty of containers out there shelling out to "newusers" with totally unvalidated input. Highly critical I'm sure. 4. cryptsetup 1.6.6-5ubuntu2.1 - CVE-2016-4484 This one only impacts the initrd of luks encrypted setups.... literally impossible to accomplish in a container. Completely garbage listing, no value, cannot possibly impact a docker container. 5. systemd 229-4ubuntu21.2 - CVE-2018-6954 This requires 'systemd-tmpfiles' to run after an attacker has manipulated the filesystem. 'systemd-tmpfiles' is not run in docker containers, and even if it did, since it starts from a fresh root filesystem each time it's a moot point since any changes the attacker makes won't persist to the next time the container "reboots" and tmpfiles runs (assuming the rare case it's run for some reason as part of the container's boot up). Another non-applicable one. 6. util-linux 2.27.1-6ubuntu3.4 - CVE-2018-7738 This one's a bug in bash-completions for umount, which aren't installed in the container by default. This one's a false positive because the vulnerable code (the bash-completions script) is not present in the docker image.

by nh2 8y ago

jes5199 8y ago

who has an app that they don’t deploy daily?

kawsper 8y ago
Many - and our deploys on weekends are almost zero.
majewsky 8y ago
I highly doubt that anyone would deploy everything daily. Your own code, maybe. But what about dependencies? Do you upgrade your Postgres container daily?
barrkel 8y ago
Some of us have contractual obligations not to deploy during the week, and require us to notify and receive permission from our customers for out of band deployments.

jrs95 8y ago

You probably shouldn’t be using Ubuntu base images anyways. The closer you can get to “scratch” the better, and the fewer security related issues you’ll have. For most use cases I think Alpine is a much better base image.

de_watcher 8y ago
That's more about trust and faith in the maintainers of the distribution (that they won't screw up).
- alexandre_m 8y ago
  It's about having the minimal number of system packages and libraries that your app actually needs. Alpine is leaner so attack surface is thinner.
- erik_seaberg 8y ago
  This. If you start adding stuff to "FROM scratch", you are creating your own obscure Linux distro. When you screw up, there are no other customers to report bugs to you, much less other maintainers to help.
  - jrs95 8y ago
    You really shouldn't be adding stuff to "FROM scratch" unless you have one statically linked binary and maybe some config files or something like that. If you actually need packages, you should use something like Alpine if possible.

TheDong 8y ago

> At the time of writing, every single image is labelled with "This image has vulnerabilities". The majority of those are not applicable in any way to your average container. I would highly encourage you to not attempt to make points off such bad data. See below for why I think it's bad data. I'd also like to point out that those CVEs are even more of a pointless thing to make such a point with since almost all of them aren't fixed in upstream ubuntu... which is to say an ubuntu server with 'unattended upgrades' would be just as 'vulnerable' as these docker containers, except moreso because more of them would actually be relevant in such an environment. Your overall point is valid, but your reference to those 'vulnerabilities' is egregiously misleading. Let me analyse as a human all the so-called "critical vulnerabilities" listed there for Xenial: 1. glibc 2.23-0ubuntu10 - CVE-2018-6485 This is exploited by C code which intentionally calls posix_memalign or aligned_alloc (instead of malloc) with unusually large arguments. There are very few codebases out there which make use of that in the first place. If your container is not running untrusted code which links against libc, you have little to fear. This CVE will not impact the average container running some ruby or nodejs application. Ubuntu also offers no update yet, so it's not actionable. 2. ncurses 6.0+20160213-1ubuntu1 - CVE-2017-10684, CVE-2017-10685 Only affects you if you're piping un-sanitized user input into an ncurses application which then displays it. I doubt there are many, if any, server applications that do this. Also not actionable. 3. shadow 4.2-3.1ubuntu5.3 - CVE-2017-12424 I'm sure there are plenty of containers out there shelling out to "newusers" with totally unvalidated input. Highly critical I'm sure. 4. cryptsetup 1.6.6-5ubuntu2.1 - CVE-2016-4484 This one only impacts the initrd of luks encrypted setups.... literally impossible to accomplish in a container. Completely garbage listing, no value, cannot possibly impact a docker container. 5. systemd 229-4ubuntu21.2 - CVE-2018-6954 This requires 'systemd-tmpfiles' to run after an attacker has manipulated the filesystem. 'systemd-tmpfiles' is not run in docker containers, and even if it did, since it starts from a fresh root filesystem each time it's a moot point since any changes the attacker makes won't persist to the next time the container "reboots" and tmpfiles runs (assuming the rare case it's run for some reason as part of the container's boot up). Another non-applicable one. 6. util-linux 2.27.1-6ubuntu3.4 - CVE-2018-7738 This one's a bug in bash-completions for umount, which aren't installed in the container by default. This one's a false positive because the vulnerable code (the bash-completions script) is not present in the docker image.