CI is failing when bind-mounting source from the host into the dev-container;
fatal: detected dubious ownership in repository at '/go/src/github.com/docker/docker'
To add an exception for this directory, call:
git config --global --add safe.directory /go/src/github.com/docker/docker
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 21677816a0)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Notable Updates
- Fix push error propagation
- Fix slice append error with HugepageLimits for Linux
- Update default seccomp profile for PKU and CAP_SYS_NICE
- Fix overlayfs error when upperdirlabel option is set
full diff: https://github.com/containerd/containerd/compare/v1.6.15...v1.6.16
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
cmd.Wait is called twice from different goroutines which can cause the
test to hang completely. Fix by calling Wait only once and sending its
return value over a channel.
In TestLogsFollowGoroutinesWithStdout also added additional closes and
process kills to ensure that we don't leak anything in case test returns
early because of failed test assertion.
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
(cherry picked from commit deb4910c5b)
Make it possible to add `-race` to the BUILDFLAGS without making the
build fail with error:
"-buildmode=pie not supported when -race is enabled"
Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>
This reverts commit 57b229012a.
This change, while favorable from a security standpoint, caused a
regression for users of the 20.10 branch of Moby. As such, we are
reverting it to ensure stability and compatibility for the affected
users.
However, users of AF_VSOCK in containers should recognize that this
(special) address family is not currently namespaced in any version of
the Linux kernel, and may result in unexpected behavior, like VMs
communicating directly with host hypervisors.
Future branches, including the 23.0 branch, will continue to filter
AF_VSOCK. Users who need to allow containers to communicate over the
unnamespaced AF_VSOCK will need to turn off seccomp confinement or set a
custom seccomp profile.
It is our hope that future mechanisms will make this more
ergonomic/maintainable for end users, and that future kernels will
support namespacing of AF_VSOCK.
Signed-off-by: Bjorn Neergaard <bneergaard@mirantis.com>
- fix linting issues
- update to go1.18.9, gofmt, and regenerate proto
- processEndpointCreate: Fix deadlock between getSvcRecords and processEndpointCreate
full diff: dcdf8f176d...1f3b98be68
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The vanity URL looks to be misconfigured;
2022-12-22T00:01:12.571Z] 2022/12/22 00:01:12 unrecognized import path "code.cloudfoundry.org/clock" (https fetch: Get "https://code.cloudfoundry.org/clock?go-get=1": x509: certificate is valid for *.de.a9sapp.eu, de.a9sapp.eu, not code.cloudfoundry.org)
This patch updates vendor.conf to fetch the code directly from GitHub.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Notable Updates
- Update overlay snapshotter to check for tmpfs when evaluating usage of userxattr
- Update hcsschim to v0.9.6 to fix resource leak on exec
- Make swapping disabled with memory limit in CRI plugin
- Allow clients to remove created tasks with PID 0
- Fix concurrent map iteration and map write in CRI port forwarding
- Check for nil HugepageLimits to avoid panic in CRI plugin
See the changelog for complete list of changes:
https://github.com/containerd/containerd/releases/tag/v1.6.13
full diff: https://github.com/containerd/containerd/compare/v1.6.12...v1.6.13
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
The twelfth patch release for containerd 1.6 contains a fix for CVE-2022-23471.
Notable Updates
- Fix goroutine leak during Exec in CRI plugin (GHSA-2qjp-425j-52j9)
full diff: https://github.com/containerd/containerd/compare/v1.6.11...v1.6.12
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Welcome to the v1.6.11 release of containerd!
The eleventh patch release for containerd 1.6 contains a various fixes and updates.
Notable Updates
- Add pod UID annotation in CRI plugin
- Fix nil pointer deference for Windows containers in CRI plugin
- Fix lease labels unexpectedly overwriting expiration
- Fix for simultaneous diff creation using the same parent snapshot
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Includes security fixes for net/http (CVE-2022-41717, CVE-2022-41720),
and os (CVE-2022-41720).
These minor releases include 2 security fixes following the security policy:
- os, net/http: avoid escapes from os.DirFS and http.Dir on Windows
The os.DirFS function and http.Dir type provide access to a tree of files
rooted at a given directory. These functions permitted access to Windows
device files under that root. For example, os.DirFS("C:/tmp").Open("COM1")
would open the COM1 device.
Both os.DirFS and http.Dir only provide read-only filesystem access.
In addition, on Windows, an os.DirFS for the directory \(the root of the
current drive) can permit a maliciously crafted path to escape from the
drive and access any path on the system.
The behavior of os.DirFS("") has changed. Previously, an empty root was
treated equivalently to "/", so os.DirFS("").Open("tmp") would open the
path "/tmp". This now returns an error.
This is CVE-2022-41720 and Go issue https://go.dev/issue/56694.
- net/http: limit canonical header cache by bytes, not entries
An attacker can cause excessive memory growth in a Go server accepting
HTTP/2 requests.
HTTP/2 server connections contain a cache of HTTP header keys sent by
the client. While the total number of entries in this cache is capped,
an attacker sending very large keys can cause the server to allocate
approximately 64 MiB per open connection.
This issue is also fixed in golang.org/x/net/http2 vX.Y.Z, for users
manually configuring HTTP/2.
Thanks to Josselin Costanzi for reporting this issue.
This is CVE-2022-41717 and Go issue https://go.dev/issue/56350.
View the release notes for more information:
https://go.dev/doc/devel/release#go1.18.9
And the milestone on the issue tracker:
https://github.com/golang/go/issues?q=milestone%3AGo1.18.9+label%3ACherryPickApproved
Full diff: https://github.com/golang/go/compare/go1.18.8...go1.18.9
The golang.org/x/net fix is in 1e63c2f08a
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This addresses a regression introduced in 407e3a4552,
which turned out to be "too strict", as there's old images that use, for example;
docker pull python:3.5.1-alpine
3.5.1-alpine: Pulling from library/python
unsupported media type application/octet-stream
Before 407e3a4552, such mediatypes were accepted;
docker pull python:3.5.1-alpine
3.5.1-alpine: Pulling from library/python
e110a4a17941: Pull complete
30dac23631f0: Pull complete
202fc3980a36: Pull complete
Digest: sha256:f88925c97b9709dd6da0cb2f811726da9d724464e9be17a964c70f067d2aa64a
Status: Downloaded newer image for python:3.5.1-alpine
docker.io/library/python:3.5.1-alpine
This patch copies the additional media-types, using the list of types that
were added in a215e15cb1, which fixed a
similar issue.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit a6a539497a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
This syncs the seccomp-profile with the latest changes in containerd's
profile, applying the same changes as 17a9324035
Some background from the associated ticket:
> We want to use vsock for guest-host communication on KubeVirt
> (https://github.com/kubevirt/kubevirt). In KubeVirt we run VMs in pods.
>
> However since anyone can just connect from any pod to any VM with the
> default seccomp settings, we cannot limit connection attempts to our
> privileged node-agent.
>
> ### Describe the solution you'd like
> We want to deny the `socket` syscall for the `AF_VSOCK` family by default.
>
> I see in [1] and [2] that AF_VSOCK was actually already blocked for some
> time, but that got reverted since some architectures support the `socketcall`
> syscall which can't be restricted properly. However we are mostly interested
> in `arm64` and `amd64` where limiting `socket` would probably be enough.
>
> ### Additional context
> I know that in theory we could use our own seccomp profiles, but we would want
> to provide security for as many users as possible which use KubeVirt, and there
> it would be very helpful if this protection could be added by being part of the
> DefaultRuntime profile to easily ensure that it is active for all pods [3].
>
> Impact on existing workloads: It is unlikely that this will disturb any existing
> workload, becuase VSOCK is almost exclusively used for host-guest commmunication.
> However if someone would still use it: Privileged pods would still be able to
> use `socket` for `AF_VSOCK`, custom seccomp policies could be applied too.
> Further it was already blocked for quite some time and the blockade got lifted
> due to reasons not related to AF_VSOCK.
>
> The PR in KubeVirt which adds VSOCK support for additional context: [4]
>
> [1]: https://github.com/moby/moby/pull/29076#commitcomment-21831387
> [2]: dcf2632945
> [3]: https://kubernetes.io/docs/tutorials/security/seccomp/#enable-the-use-of-runtimedefault-as-the-default-seccomp-profile-for-all-workloads
> [4]: https://github.com/kubevirt/kubevirt/pull/8546
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
(cherry picked from commit 57b229012a)
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
