Fixes the following security vulnerabilities:
- CVE-2019-14271: In Docker 19.03.x before 19.03.1 linked against the GNU C
Library (aka glibc), code injection can occur when the nsswitch facility
dynamically loads a library inside a chroot that contains the contents of
the container
Signed-off-by: Christian Stewart <christian@paral.in>
[Peter: mention security impact]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All these packages have an upstream-provided service, but buildroot
enabled manually the services in exactly the same way as the [Install]
section.
This is not needed anymore
Signed-off-by: Jérémy Rosen <jeremy.rosen@smile.fr>
[yann.morin.1998@free.fr: fix check-package errors]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Fixes the following security vulnerability:
CVE-2019-13509: Docker Engine in debug mode may sometimes add secrets to the
debug log. This applies to a scenario where docker stack deploy is run to
redeploy a stack that includes (non external) secrets. It potentially
applies to other API users of the stack API if they resend the secret.
And a number of other non-security issues.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fixes CVE-2018-15664: API endpoints behind the 'docker cp' command are
vulnerable to a symlink-exchange attack with Directory Traversal, giving
attackers arbitrary read-write access to the host filesystem with root
privileges, because daemon/archive.go does not do archive operations on a
frozen filesystem (or from within a chroot).
And includes additional post-18.09.6 fixes:
Builder
- Fixed a panic error when building dockerfiles that contain only comments.
moby/moby#38487
- Added a workaround for GCR authentication issue. moby/moby#38246
- Builder-next: Fixed a bug in the GCR token cache implementation
workaround. moby/moby#39183
Runtime
- Added performance optimizations in aufs and layer store that helps in
massively parallel container creation and removal. moby/moby#39107,
moby/moby#39135
- daemon: fixed a mirrors validation issue. moby/moby#38991
- Docker no longer supports sorting UID and GID ranges in ID maps.
moby/moby#39288
Logging
- Added a fix that now allows large log lines for logger plugins.
moby/moby#39038
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
On Github, a large number of projects name their tag vXYZ (i.e v3.0,
v0.1, etc.). In some packages we do:
<pkg>_VERSION = v0.3
<pkg>_SITE = $(call github foo,bar,$(<pkg>_VERSION))
And in some other packages we do:
<pkg>_VERSION = 0.3
<pkg>_SITE = $(call github foo,bar,v$(<pkg>_VERSION))
I.e in one case we consider the version to be v0.3, in the other case
we consider 0.3 to be the version.
The problem with v0.3 is that when used in conjunction with
release-monitoring.org, it doesn't work very well, because
release-monitoring.org has the concept of "version prefix" and using
that they drop the "v" prefix for the version.
Therefore, a number of packages in Buildroot have a version that
doesn't match with release-monitoring.org because Buildroot has 'v0.3'
and release-monitoring.org has '0.3'.
Since really the version number of 0.3, is makes sense to update our
packages to drop this 'v'.
This commit only addresses the (common) case of github packages where
the prefix is simply 'v'. Other cases will be handled by separate
commits. Also, there are a few cases that couldn't be handled
mechanically that aren't covered by this commit.
Signed-off-by: Victor Huesca <victor.huesca@bootlin.com>
[Arnout: don't change flatbuffers, json-for-modern-cpp, libpagekite,
python-scapy3k, softether]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Additional post-18.09.5 fixes:
Builder:
- Fixed COPY and ADD with multiple <src> to not invalidate cache if
DOCKER_BUILDKIT=1.moby/moby#38964
Networking:
- Cleaned up the cluster provider when the agent is closed. docker/libnetwork#2354
- Windows: Now selects a random host port if the user does not specify a
host port. docker/libnetwork#2369
- --service-cluster-ip-range is now configurable for UCP install.
docker/orca#10263
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The hidden Config.in option BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS name is
not very clear as to whether it says whether Go is available for the
target architecture or the host architecture.
Until now, this was fine since there was support for host Go
packages. But as we are about to introduce support for building host
Go packages, we need to clarify the meaning of
BR2_PACKAGE_HOST_GO_ARCH_SUPPORTS. Since it says whether the target
architecture has support for Go or not, we rename it to
BR2_PACKAGE_HOST_GO_TARGET_ARCH_SUPPORTS.
And since BR2_PACKAGE_HOST_GO_CGO_LINKING_SUPPORTS is tightly related,
we rename it to BR2_PACKAGE_HOST_GO_TARGET_CGO_LINKING_SUPPORTS.
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
Tested-by: Adam Duskett <aduskett@gmail.com>
[Thomas: entirely rewrite commit log]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Fixes:
http://autobuild.buildroot.net/results/63e9d88ae5177541be463f1e2aafec59aa410479
Add dependency on headers >= 3.11 for O_TMPFILE, used by runc after the
fix for CVE-2019-5736 and propagate to the reverse dependencies of runc.
Notice that C library support for O_TMPFILE is also needed, which was added
in glibc 2.19 and musl 0.9.15.
Signed-off-by: Christian Stewart <christian@paral.in>
[Peter: squash series, extend commit message, mention C library dependency,
fix indentation]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the startup warning from Docker:
failed to retrieve runc version: unknown output format: runc version commit ...
Introduces a patch to replace the faulty version detection logic in the Docker
engine.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The vulnerability allows a malicious container to (with minimal user
interaction) overwrite the host runc binary and thus gain root-level
code execution on the host. The level of user interaction is being able
to run any command (it doesn't matter if the command is not
attacker-controlled) as root within a container in either of these
contexts:
* Creating a new container using an attacker-controlled image.
* Attaching (docker exec) into an existing container which the
attacker had previous write access to.
For more details, see the advisory:
https://www.openwall.com/lists/oss-security/2019/02/11/2
The fix for this issue uses fexecve(3), which isn't available on uClibc, so
add a dependency on !uclibc to runc and propagate to the reverse
dependencies (containerd/docker-engine).
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since commit de336584d2 (package/docker-engine: split docker-{cli, engine},
bump to v18.09.0), the docker-engine package only builds the daemon part,
and the .mk file no longer use the _DAEMON option, so drop it.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Tested-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Docker upstream has split the Docker daemon and CLI into separate
codebases:
- github.com/docker/engine: daemon, "dockerd" binary
- github.com/docker/cli: "docker" command line interface
This commit splits the docker-engine package into docker-engine and
docker-cli. Conveniently, the Docker project has begun maintaining
two separate release-tagged repositories for the CLI and daemon as of
v18.06-ce-rc1. Previous versions were tagged in a common "docker-ce"
repository which makes compilation awkward for Buildroot, especially
due to some limitations in the new Go package infrastructure.
Docker repositories "engine" and "cli" recently started tagging
releases. Select the latest stable release, v18.09.0.
The CLI is no longer automatically included with the engine. Users
will need to select BR2_PACKAGE_DOCKER_CLI to produce a both docker
and dockerd target binaries.
Docker CLI can be statically compiled. This enables usage of the
system docker client binary to access the parent daemon API from
within containers, where shared libraries are not available.
While at it, drop the useless host-go dependency from docker-engine,
since it's already added by the golang-package infrastructure.
Signed-off-by: Christian Stewart <christian@paral.in>
[Thomas: drop the host-go dependency from both docker-cli and
docker-engine]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Angelo Compagnucci <angelo@amarulasolutions.com>
[Thomas:
- adapt to the changes in the golang-package infrastructure
- keep the logic to support BR2_PACKAGE_DOCKER_ENGINE_STATIC_CLIENT]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
docker-proxy is needed by docker-engine at runtime, and was
previously not included. This leads to the following error
when attempting to port-map ports to a container:
$ docker run -p 8080:8080 nginx
docker: Error response from daemon: driver failed programming external
connectivity on endpoint:
exec: "docker-proxy": executable file not found in $PATH.
Docker expects the docker-proxy binary to exist in the PATH.
Signed-off-by: Christian Stewart <christian@paral.in>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since things are no longer installed in $(HOST_DIR)/usr, the callers
should also not refer to it.
This is a mechanical change with
git grep -l '$(HOST_DIR)/usr/bin' | xargs sed -i 's%$(HOST_DIR)/usr/bin%$(HOST_DIR)/bin%g'
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Christian Stewart
Fabrice Fontaine
Jérémy Rosen
Peter Korsgaard
Victor Huesca
Angelo Compagnucci
Matt Weber
Arnout Vandecappelle